[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