[svk-users] Smerge, and best practices for working branches?

[Ruslan Zakirov]

On Fri, Feb 8, 2008 at 1:57 AM, Brooks Moses <brooks at codesourcery.com> wrote:
> 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?
There is not many clever things svk can do about that. If you merge a
change from A to B and then merge back from B to A then svk will merge
everything back and often changes you have in B that came from A will
not result in conflicts, but instead those will be empty changes.

To avoid many redundant changes in a branch I often use bundled merges
(not interactive smerge) from trunk into a branch (A -> B). I do that
before pushing my changes back into trunk from a branch, so I resolve
all conflicts first, test that the branch still works and merge back
into trunk.

>
>  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....
Yep, as I wrote above it could be a case, however if you resolved a
conflict in a file then next change in that file will use new base and
there is good chances that svk can resolve merge without interacting
with you.

>
>  (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


-- 
Best regards, Ruslan.