Version non-control

Written early in the evening in English • Tags:

What am I doing wrong? I’m using svk to mirror a public svn repository. I use a local copy of the mirror for committing my changes for testing on my own sites before proposing patches for upstream. When I want to merge in upstream changes, I end up losing all my local changes as well. This is not supposed to happen!

This is how I initially set up the local repository:

svk mirror //mirror/project
svk sync //mirror/project
svk mkdir //local/project
svk cp //mirror/project/trunk //local/project/trunk

Then I check out my working copy, make changes and commit:

svk co //local/project
cd project/trunk
vi file.php
svk commit

Now let’s retrieve new upstream changes:

svk sync //mirror/project
svk smerge //mirror/project/trunk //local/project/trunk

Now I get a list of files that succeed and then a bunch of questions about what to do with locally changed files and — surprisingly — some files that don’t have any local modifications. Maybe they had in the past — I’m not sure.

My choices are to pick the upstream version (“theirs”), my local version (“yours”) or merge them (“merge”). I haven’t actually tried merging yet, since the d (diff) and especially the dm (diff merged) show basically useless information: they show the diff between the last committed version and a file that has both the old and the new version. So basically I see the complete new (“theirs”) version with a plus sign prepended on each line.

Maybe I’m trying to use a version of svk that is too old? I’m using version 1.00-1 from Debian Linux.

Maybe I haven’t followed the tutorials (SVK Tutorial and SVK Usage) correctly? I guess I could try to find other tutorials in addition to the SVK Wiki.

Should I use merge or smerge?

Maybe I should try to use a separate working copy as the destination of the merge (or smerge) instead of trying to do it in the depot directly?

It sounds so simple but I’m not getting what I expected. Practical examples needed…