You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Ni...@infineon.com on 2007/10/26 09:42:31 UTC
Merging between branches and the trunk after code refactoring
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...?
Thanks,
Nick.
Re: Merging between branches and the trunk after code refactoring
Posted by Stefan Sperling <st...@elego.de>.
On Fri, Oct 26, 2007 at 02:04:19PM +0200, Nick.Thompson@infineon.com wrote:
> 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.
You have Use Case 6 described in the paper attached to issue 2282.
At the moment we are trying to get the first 3 use cases sorted
out, the other ones will be dealt with later. See the paper for
the description of use case 6 (the paper is in power point format,
unfortunately).
> 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 user should get a tree conflict because the renames conflict.
How the conflict is dealt with is totally up to the user.
But Subversion should signal the conflict and possibly provide
some reasonable default solution.
> 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.
We cannot implement true renames without removing the ability
of checking out subsets of the versioned directory tree stored
in the repository.
(At least according to Karl, that is the problem with true renames.)
> 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?
I'm not sure. I'm concerned with trying to fix the issue so
that subversion supports your use case as good as possible,
without workarounds.
--
Stefan Sperling <st...@elego.de> Software Developer
elego Software Solutions GmbH HRB 77719
Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96
13355 Berlin Fax: +49 30 23 45 86 95
http://www.elego.de Geschaeftsfuehrer: Olaf Wagner
RE: Merging between branches and the trunk after code refactoring
Posted by Ni...@infineon.com.
> -----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
Re: Merging between branches and the trunk after code refactoring
Posted by Stefan Sperling <st...@elego.de>.
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=thread&from=362008
Any ideas welcome.
--
Stefan Sperling <st...@elego.de> Software Developer
elego Software Solutions GmbH HRB 77719
Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96
13355 Berlin Fax: +49 30 23 45 86 95
http://www.elego.de Geschaeftsfuehrer: Olaf Wagner