Sussman said dev@ might be also interested in the copy-merge support.
> 寄件人: Chia-liang Kao <firstname.lastname@example.org>
> 日期: 2005 八月 18 17:52:38 GMT+01:00
> 收件人: email@example.com, firstname.lastname@example.org
> 標題: copy across merge support
> 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.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Thu Aug 18 19:37:56 2005