> -----Original Message-----
> From: Stefan Sperling [mailto:stsp@elego.de]
> Sent: 26 October 2007 12:02
> To: Thompson Nick (IFAG)
> Cc: users@subversion.tigris.org
> Subject: Re: Merging between branches and the trunk after
> code refactoring
>
> On Fri, Oct 26, 2007 at 11:42:31AM +0200,
> Nick.Thompson@infineon.com wrote:
> > Hi,
> >
> > Yesterday I was asked how to complete a merge from trunk, to a
> > branched WC, when the branched code had been refactored.
> The merge
> > from the trunk specified a revision range where certain files
> > where in one directory, but the equivalent files and been moved
> > (copy-with-history + delete) to another dir. The merge failed
> > because in the 1.4.x series subversion doesn't have a "proper"
> > rename function and can't find the files, so can't apply
> the merge
> > "patch".
> >
> > Q: What is the best practice for completing such a merge?
> >
> > My answer was: Complete the refactoring operation again on the
> > trunk (the to-branch merge was a pre merge-back-to-trunk updating
> > activity) and then merge. Is there a better solution? Presumably,
> > 1.5.0 of Subversion will not help and nothing short of completing
> > the proper renaming issue will...?
>
> This is a tree conflict problem. Subversion should detect the
> conflicting moves and signal conflicts appropriately.
> This is not easy to solve.
>
> See the following:
> http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=131681
> http://subversion.tigris.org/issues/show_bug.cgi?id=2282
> http://subversion.tigris.org/servlets/BrowseList?list=dev&by=t
> hread&from=362008
>
> Any ideas welcome.
Yes, that's interesting and certainly related, but I don't think my
use-case is quite as bad, though maybe not adequately described :-). In
my case, the user has a *pristine* working copy from a branch that has
had code refactored (relative to the trunk) but already committed. In
this case the user doesn't get tree-conflicts as such (which can lead to
revertions etc.) but rather the merge fails as the target files for some
files being merged from the trunk do not have the same names on the
branch (and hence in the working copy). The difference here, is that a
true rename function could allow the merge to complete with less
difficulty than the UC's defined in the tree conflict scenarios.
Duplicating the refactoring on the trunk (and committing it) before
merging to the branch is the best solution I could think of in my case.
Is there a best practice for my scenario that I failed to consider?
Thanks,
Nick.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Oct 26 14:04:57 2007