Hi All,
Apart from svk 1.03 is to be released later today, I am delighted to
announce the support for copies across merge has just landed svk
trunk. While this won't be in the 1.0x line, I am planning for a
development release around the end of the month at YAPC::Europe.
The copy-across-merge support in svk is sponsored by Fotango.
You can use the feature with your Subversion repository while
performing merge, without requiring everyone to use svk.
= The problem
Most of you already know how to do branching and merging in
Subversion. A simple scenario for branch catching up trunk changes:
svn cp URL/trunk URL/branches/foo - Committed r120
# hack hack hack on foo branch
svn merge -r120:HEAD URL/trunk URL/branches/foo - Committed r150
(in fact you can't do this with svn, you have to checkout foo first,
merge and commit)
And some of you probably know svk does the boring part for you:
finding out the numbers to use in merge command.
svk smerge --to //branches/foo
will do the merge for you.
However, consider the change r151 on trunk:
D /trunk/dirA
A /trunk/dirB (from /trunk/dirA:150)
If you made some changes to /branches/foo/dirA/bar, try to merge
things from trunk:
svn merge -r150:HEAD URL/trunk URL/branches/foo
It will merge without a conflict in foo branch:
D /branches/foo/dirA
A /branches/foo/dirB (from /trunk/dirB:151)
No wait! what about the local changes to dirA/bar?
While this example is for merging things from trunk to branch, it is
the same story when you do merge back from branch. Now you have to
keep in mind when using subversion, not to do renames on a branch and
merge back.
So you can only do tree reorganisations on trunk, and hope there are
no other branches active for the time being.
The whole problem is mainly due to svn merge doesn't track history,
which is no news. svk has been handling this a bit more sensible,
but not ideal.
A conflict would happen when trying to delete branches/foo/dirA,
because things have been changed since it was branched. And then dirB
will be created as new directory along with all content, without
history, which is literally a copy from /trunk/dirB:151 as well.
Until now.
using svk smerge --to //branches/foo will give you:
D /branches/foo/dirA
A /branches/foo/dirB (from /branches/foo/dirB:150)
The copy source revision will be mapped to where the node was last
merged, and local modification will be merged along with remote
changes during the merge.
= Technical details
This wasn't implemented because the main Subversion API used for
generating tree delta, svn_repos_dir_delta, does not generate history
information. So I implemented an editor, which takes incoming editor
calls from dir_delta, with certain callbacks to decide if we want to
turn a call into add or replace with history, then feed the add-with-
history call along with the appropriate tree delta under it, to the
original editor.
So instantly we also get the ability to show diff against its
copybase, rather than showing the full file.
Cheers,
CLK
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Aug 18 18:58:00 2005