[svk-devel] svk 2.0 confusing messages

[Andrew Ruder]

On Sat, Jan 13, 2007 at 10:02:48AM +0200, Alexandru Popescu wrote:
> After running 15 or 20 times the above commands the messages got away.
> I got the impression that what solved the problem was running a smerge
> command with the synch mirror option. Frankly speaking I still belive
> this is a bug, but considering that nobody commented on it makes me a
> bit uncomfortable calling it so.

As Viktor wrote, the "problem" is that svk does not make a commit
without some sort of data change.  svk keeps track of what it has merged
in a property, so in order to keep track of what has been merged it must
have a commit to do so on.

Example:

You have merged up to revision 2 of remote/trunk in your local/trunk

If you do svn proplist -v file:///home/<yourusername>/.svk/local/trunk

You will see something like:
  svk:merge : 13f7ca84-9c03-0410-bd7d-801fa6cd78ca:/:2

It is that property that is keeping track of what you have merged so
far.

You make a change in remote/trunk AND in local/trunk (the same change).

You do a smerge, it says 'Empty Merge' and nothing is committed.  The
problem is now that since it didn't make a commit it could not update
the svk:merge property on local/trunk.  The next time you do an smerge,
it once again sees that it has up to revision 2, so it does the empty
merge again.

Now let's say you make another change on just remote/trunk (revision 4)

You do the smerge, you will see the 'Empty Merge' for revision 3, then
it will merge revision 4's changes.  Now, when it merge's revision 4's
changes, it can make a commit and therefore update that svk:merge
property to say its got revisions 1-4.

In short, without a commit happening, svk can not keep track of what it
has merged already so you will continue getting empty merge's until you
make a real commit that has changes to merge.  I personally much prefer
it this way as I would -=not=- want svk making commits all the time just
to update its metadata.  (It would make the log on local/trunk much
harder to follow).

Cheers,
Andy

-- 
Andrew Ruder <andy at aeruder.net>
http://www.aeruder.net