views:

30

answers:

3

For a very long time we did all of our development and deployment from trunk. After a while this led to a production environment that was out of synch with trunk as we'd get a request to move new feature "B" to production, but hold off on new feature "A" - basically we'd checkout from trunk to a temp folder then selectively merge files from temp to production (which wasn't under version control)

After wrestling with this for far too long, I finally decided to rearrange the repository to allow for branching, but I made a few mistakes while moving (svn mv) trunk around so that I could make room for the branches and tags folders (previously there was no "trunk" folder, the files just sat in the parent folder for the project) and the end result is that my "trunk" is now newer than some of the branches I created off of it. And now I can't seem to do a merge from the branches back into trunk w/o missing lots of changes and getting lots of conflicts. (I've already updated the branch from trunk.)

If I run svn log --stop-on-copy on my trunk, the earliest revision is r14376, and if I run it on my branch the earliest revision is r14368. (HEAD is at r14710)

How can I do a proper merge without losing all of my changes between r14368 and r14376? I was just going to do a manual merge to trunk, but then I lose all of my revision history for the branch files.

A: 

Nevertheless I gave you a point for question, My statement is that you should should be aware of what you are doing. So no one in company will be mumbling that sth is not working, .... Read on merging in svn book:
http://svnbook.red-bean.com/en/1.5/svn-book.html#svn.branchmerge.advanced.advancedsyntax

Gadolin
I read that section last night, but either I'm not understanding it or the examples I tried don't apply to my situation.
Chrisbloom7
A: 

It's hard to answer without seeing more details of what's going on with your repo, but perhaps you could delete the current 'trunk' folder, then copy the original pseudo-trunk (i.e., the repo root) into a trunk folder in HEAD. I think this will give you the original pseudo-trunk as a new 'trunk' folder with history intact. Assuming you first started modifying the repo root in rX, the commands would be something like this:

svn rm url/trunk
svn commit -m "Removing broken trunk"
svn cp -rX url/@X url/trunk
svn commit -m "Creating new trunk from previous root"

You can then try merging your branch back into the trunk. If you have conflicts with trunk code, try merging all the revisions minus the ones where you brought in the trunk code (I'm assuming, perhaps errantly, that you do trunk updates as isolated commits).

mr. w
As a result of the way I moved the files around in the reorganization I am no longer able to refer to any revision before r14360. I didn't plan the whole thing out a head of time and very nearly lost the whole thing in the process. Mark it up as a lesson learned, but the end result is that I don't have the option of doing as you suggest.
Chrisbloom7
What did you do that you can't refer to a revision prior to 14360? Short of creating a new repository and importing the files fresh to remove all history, I can't think of anything that would prevent you from referring to an earlier revision. Even if you move things around, delete things, etc., those earlier revisions still exists and should still be usable. Note that I used a peg revision ("@X") in the cp command; this will enable your old paths to work even though they no longer exists in HEAD. Was that the part causing trouble?
mr. w
+1  A: 

I toyed around with a few different ways of writing the merge command and think I finally got what I needed. I essentially reversed the order of the merge arguments so that younger trunk came first followed by the older branch, and I then merged those into a working copy of trunk:

$ cd trunk
$ svn update
$ svn merge svn://server/project/trunk@14376 svn://server/project/branches/46@14710 .
--- Merging differences between repository URLs into '.':

This resulted in only a handful of conflicts, most of which were on image files which I just accepted the right-hand copies of. And hopefully this puts me in a place where future branches and merges will work normally.

Chrisbloom7