views:

130

answers:

4

Hi all,

my company'scode is in a subversion repository, and it has worked well so far. I followed the advice on how to setup the repository, i.e. I have branches/tags/trunk sub-directories. But I now want to be a bit more organised, and have 2 meta-branches, dev and release. The former is obviously for development purpose, where the engineers can try different weird things , whereas the latter would be for stable code that is product-ready. All new features would first live in "dev" while being developed, and once deemed ok, they would be merged onto the "release" branch once in a while. Commit to the "release" would only come from such merges plus normal bug. Each of these meta-branches would contain the normal branches/tags/trunk sub-directories.

The problem I have is I cannot for the life of me set this up. I have created the 2 meta-branches, moved all the existing subdirectories into "dev", and I now want to move the "dev"'s trunk into the "release" trunk. But I cannot figure how to. If I switch (from TortoiseSVN), it simply deletes everything, because the "release" trunk is empty. If I try to create a branch 'release/trunk' from 'dev/trunk', tortoisesvn complains that the path does not exist.

I cannot figure out what to do. This should be simple shouldnt it? I'd guess many people uses a similar organization, dev vs. release?!

Any advices/comments/ideas welcome.

Thanks in advance.

A

+3  A: 

The way this is typically done, the project has just one set of branches/tags/trunk directories at the top level of the repository. The trunk directory is your "dev" meta-branch, and you create a branch of the trunk under your branches directory called "release" to serve as your stable, product-ready branch. If you need to track multiple releases (like v1.0 and v2.0) then you'd have both a "1.0" and a "2.0" under branches. When you're ready to release the code, you make a tag with the version number from the appropriate release branch.

I think what you're trying to do will make the repository structure overcomplicated. You can achieve everything you need to do with a single branches/tags/trunk set.

That said, branches are most easily created with TortoiseSVN by navigating the Repo-Browser to the directory you're copying from ("dev/trunk" in your case), right-clicking that folder, selecting "Copy To", and entering the path to the new branch ("release/trunk") in your case.

Nick Meyer
Agreed. It should be and indeed is that simple. Tag your releases and develop in the Trunk.
Paul Sasik
Good advice (though I'd say it doesn't really answer the question -- I think he still needs to know how to physically accomplish what you suggest with TortoiseSVN). +1.
j_random_hacker
@j_random_hacker: Added that advice too.
Nick Meyer
+1  A: 

From within the Repo-browser, right click on the directory your source code is residing (trunk?) and select "Copy to...".

But indeed you may want to rethink the structure.

Andreas
A: 

Open TortoiseSVN's Repo-browser (by right-clicking anywhere in an Explorer directory listing), navigate to your dev directory, right-click it and select "Copy to...". Now specify the destination. This operation will occur as a single commit, so you will be asked for a log entry.

I'm running a slightly older TortoiseSVN (v1.4.8) but I'm sure this or something similar will work.

j_random_hacker
A: 

The setup you describe is usually called "feature branches". I.e. you develop a new feature on a separate branch and once it is complete you merge it back to the trunk (which is always kept at a stable version). The repository structure might then look like this:

/trunk
/branches/featureX
/branches/featureY
/tags

Development of a feature would then work like this:

  • you create the branch for the feature to be developed (a copy of trunk)
  • while you develop the feature on that branch, you may periodically merge any changes made on trunk into your branch. This is done to keep the difference between trunk and feature-branch as small as possible
  • once your feature is complete, you reintegrate the branch into trunk and then delete the feature-branch

You can find more information about this scenario and the commands involved in the subversion book or in the TortoiseSVN help.

M4N