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

[Jim Hague]

On Tuesday 08 August 2006 18:12, Ruslan Zakirov wrote:
> On 8/8/06, Jim Hague <jim at bear-cave.org.uk> wrote:
> > 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.

Thanks for responding. I agree on a test file; when time permits I shall have 
a go at making one.

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

Yes, that looks like what I see.

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

OK, thanks. That makes sense.
-- 
Jim Hague - jim at bear-cave.org.uk        Never trust a computer you can't lift.