Forwarding to dev@ list, because not everyone reads users@.
Begin forwarded message:
> From: Chia-liang Kao <clkao@fotango.com>
> Date: August 18, 2005 11:52:38 AM CDT
> To: users@subversion.tigris.org, svk-dev@lists.openfoundry.org
> Subject: 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,
> CLK
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
---------------------------------------------------------------------
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:35:00 2005