When SVN was set up, instead of creating a branch from trunk, we simply created a new folder in the root structure:
/branches/dev/
/trunk
and worked on that. Now, of course, it’s impossible to merge dev into trunk as SVN doesn’t see a hierarchical connection. I’m trying to find the best way to make it proper, so that the dev branch we have our code in is related to trunk and we can do normal merges in the future.
I found two approaches – one of them simply copy code from dev to trunk, commit trunk, and then do a proper branch checkout. My problem with this approach is that we’d lose all the revision history, as the real dev branch would start out fresh.
Other approach is to use –ignore-hierarchy. This seems like forcing stuff into trunk and I’m unsure of the downsides of this approach.
Basically what’s the best way to fix the screw-up from the beginning, when we physically created dev folder on our own, instead of branching trunk?
Why can’t you merge that branch into trunk?
There are different ways to maintain branches and the like inside subversion (and every other rcs). What you intuitively set up is the traditional way: you create folders and copy differences between folders revisions between branches/trunk/tags. That works, since to svn a node in the hierarchy is nothing but a folder. There is no special magic in svn.
Subversion is nothing but a file system with an additional time axis.
So all you have to do is merge the changes (revisions) you committed to the branch node into the trunk:
(That is: if your branch initially contained some revision of the trunk. But I assume it did, since you did not say otherwise. If it is completely independent from the trunk then why is it called a branch? And: more important: why do you want to merge it into the trunk?)
Update 2013-01-26:
Discussion revealed that the situation involved an empty trunk, never populated and never used, so nothing to merge any changes from a branch into. Instead the whole development originated and was made in something called a ‘branch’ which in reality served as the sole ‘trunk’ for this project.
So the solution appears like this:
In this case simply move what is currently called branch to be the projects trunk and continue development under that new (and better fitting) name. Developments are done either inside new checkouts or by rebasing existing checkouts. Branches should from now on be used the way described below. So correct the missfitting names and adjust the current situation so that it matches the typical wording of projects: