[svk-users] Smerge, and best practices for working branches?
Brooks Moses
brooks at codesourcery.com
Thu Feb 7 17:57:18 EST 2008
Hello!
I'm trying to understand how smerge works in cases with a working
branch, and how best to handle bi-directional change merges.
(As a note: we're not using a remote repository and local depots;
everything is done directly in the main repository. That simplifies
things a bit.)
Suppose that we have a trunk directory /A, and we copy a branch off of
it, /B. I'd like to keep /B up-to-date with changes that other people
make to /A, and I'm also making changes to /B that I'd like to
occasionally merge back to /A.
So, the process starts out like this:
1) copy /A to /B.
2) make changes in /B and commit them.
3) smerge from /A to /B to get /B up-to-date.
4) repeat 2 and 3 as desired.
What I am having difficulty with is figuring out what happens when I
then smerge from /B to /A. My understanding is that this will attempt
to take all of the changes that were applied to /B since step 1, and
merge them into /A. What happens to the changes to /B caused by the
merge in step 3? Are those simply treated as the other changes, with
the hopes that merging them back to /A will just not have any conflicts,
or does smerge do something more clever?
It seems to me that, especially if I am attempting to do an incremental
smerge from /B to /A, this is likely to cause difficulties if the same
file has been repeatedly edited in /A and merged to /B....
(On the other hand, if smerge simply ignores the commits to /B that came
from merges from /A, then that is likely to lose any local edits that I
may have made in resolving conflicts and included in that commit, which
is also a problem.)
Thanks for any light that people can shed on this!
- Brooks
More information about the svk-users
mailing list