On Tue, Jul 17, 2012 at 10:16:13AM -0400, Jamie Jackson wrote:
> I have a dozen outstanding feature branches (based on the trunk), and
> I need to rename a subdirectory. Since I've got so many branches, I
> want to make sure I'm doing things properly.
>
> Here's how I plan to do this, and propagate the change to the branches:
>
> TRUNK
> 1. Rename the directory (and commit).
> 2. Change any code to reflect the new directory name (and commit).
>
> BRANCH
> 3. Merge in step 1.
> 4. Resolve the resulting tree conflict with "mine-full".
Your step 4 won't work as you expect since Subversion isn't that
intelligent yet. Tree-conflicts can only be resolved to "working"
state currently, which means you have to put the working copy
into the desired end state yourself and mark the conflict resolved.
Has the directory also been renamed on the branch?
If so, you'll probably get an "incoming delete vs. local missing"
conflict, and you'll need to run a subtree merge from the renamed
directory on trunk into the corresponding subtree in the merge target.
If it hasn't been renamed, you'll probably get an "incoming delete
vs. local edit" conflict in case files with the directory have been
changed on the branch, and you'll need to move your branch-local
changes over to the new location (e.g. by merging from the target
branch's own history into the new dir, or by manually moving changes over).
> 5. SVN rename the changed directory (and commit).
This isn't necessary.
The addition of the new directory on trunk will also be merged, in addition
to the deletions discussed above. You'll probably want to commit after
merging any branch-local changes into this newly added directory (copied
from trunk). A conflict won't be flagged here unless the target branch
also has a new directory or file with the same name.
> 6. Merge in step 2 (and commit).
>
> Is that the standard approach?
>
> Notes:
> * I don't like how 1 and 2 are separate commits, but it seems inevitable.
> * 3-5 could be done with record-only-merge, but 3-5 seems to have the
> advantage that the eventual branch-to-trunk merge will have this merge
> revision ignored.
In these cases, making separate commits can help a lot when navigating
through the mess. If you accumulate all these change in the working
copy before commit it will be hard to figure out later what you did
to resolve conflicts.
Received on 2012-07-17 16:33:22 CEST