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.
