[svk-devel] smerge --incremental committing empty changes

Ruslan Zakirov ruslan.zakirov at gmail.com
Tue Aug 8 13:12:35 EDT 2006


On 8/8/06, Jim Hague <jim at bear-cave.org.uk> wrote:
> For some time now I have been using svk to keep two Subversion repositories
> in sync. One is the main repository, the other a satellite on a network
> only accessible via VPN. Most changes are committed to the main repository,
> but circumstances dictate that some have to be committed to the satellite.
> So I have mirrors of each repository and smerge between the two with the
> VPN enabled as appropriate.
>
> When smerging between the two, I prefer to use --incremental, particularly
> when merging up from the satellite to the main; the Bugzilla integration
> needs it.
>
> I have found that particularly if I don't merge frequently I get trouble
> if there is a merge conflict. Suppose I resolve a conflict in foo.c in favour
> of the main repository; what seems to happen is that an empty change is
> committed to foo.c in the main repository. When SVK moves on to consider
> the next change in the satellite to be uploaded, the same conflict in
> foo.c is presented, I repeat the resolve, and get another empty change
> committed. After a while the change log for foo.c has a blizzard of
> empty changes. Is this right/expected? Pilot error?
I see this two sometimes, but have no idea how to reproduce it with
test file. If you can write such file then it would cool and
developers would be able to fix it faster.

As I understood next things happen:
1) you start interactive merge
2) svk choose rev from x to y.
3) x revision has a conflict in file foo
4) you resolve conflict and result is empty merge
5) svk decide that it shouldn't commit anything, but also leave props unchanged
6) then svk moves to revision x+1, but because of some unknown reason
it tries to merge revisions x(again) and x+1 at once and you have to
resolve conflicts in x again...

Something like that.

>
> When this happens, I usually get out of jail by doing a non-incremental
> merge, which does what I expect.
>
> I must admit that I'm also slightly confused by the 'yours' and 'theirs'
> terminology. Am I right in thinking if I am running
>
>         svk smerge -I //mirror/reposA //mirror/reposB
>
> that 'yours' refers to the contents of reposA and 'theirs' is reposB?
> If so, what is 'Original' when I diff?
Original is common base for two. In the simple situation when repoA is
copy of repoB, base is repoB at some old revision, for example: you
copied A from revision 1 of B, then commited several revisions to B
and A, and want to merge then base(original) would be B at 1.


>
> As you can tell, I'm not really sure what is going on in an smerge.
> Can anyone point me at an explanation of the smerge?  I've been
> Googling 'star merge' without success so far.
> --
> Jim Hague - jim at bear-cave.org.uk          Never trust a computer you can't lift.
>
> _______________________________________________
> svk-devel mailing list
> svk-devel at bestpractical.com
> http://lists.bestpractical.com/cgi-bin/mailman/listinfo/svk-devel
>


-- 
Best regards, Ruslan.


More information about the svk-devel mailing list