[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Fwd: copy across merge support

From: Chia-liang Kao <clkao_at_fotango.com>
Date: 2005-08-18 19:24:35 CEST

Sussman said dev@ might be also interested in the copy-merge support.


> 寄件人: Chia-liang Kao <clkao@fotango.com>
> 日期: 2005 八月 18 17:52:38 GMT+01:00
> 收件人: users@subversion.tigris.org, svk-dev@lists.openfoundry.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.
> Cheers,

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Aug 18 19:37:56 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.