SVN tags and branches

Mort

Mort

Mort

Associate
Joined
18 Oct 2002
Posts
1,312
Location
Milton Keynes
Hey all

Looking for users of subversion. First off I have read The Book. I have been using svn for a while to track projects and used for collaboration etc, but I dont think I am getting as much out of it as I could. Although the book has given me a basic understanding of how branches and tags work, because there is so much to read on the subjects its a bit overkill really.

Found a good diagram here ( http://en.wikipedia.org/wiki/Subversion_(software)#Branching_and_tagging ), but could still do with confirmation from a fellow user about how it is best used and implemented.

Example for website version control. We have an in house framework, which would be in the trunk. Then if we have a set release say 2.5 that would be a tag, no further commits would happen on this copy and would be for archiving only. Then say we wanted to make a new site that would be using the framework, this would be a branch that would take the current trunk as a start point and have new development go from there. If we develop something that would need to go into the main trunk, would it just be a case of merging those files with the trunk?

This sound about right? If not please point me in the right direction. Also would be interested in hearing about other peoples use and management of SVN and their projects, from lone devs to collaborative teams.

Cheers
 
I use subversion at work too but i dont really manage any of it.

we work in a sort of agile process where each developer could be working on his or her work package and they would have their own branch if needed. once development and testing has been completed on that branch, it would be merged into the trunk or the current release branch that contains bug fixes etc.

ideally we could make a tag at that point but we dont :(.

I see subversion as a very powerful tool when you work on different large projects on the same codebase especially when you integrate it with continuesous integration tools such as Hudson or Cruise control.
 
What type of framework are you refering too? If it's a collection of ASPX/PHP libraries etc then personally I would have one trunk/tag/branch system for the libraries and one for each additional project. This allows you to check out the latest version of the libraries and compile your websites with them, or to come back in the future and checkout the latest version of the framework and recompile it if needed.
 
I usually use branch to test out features or ideas, and if they work nicely, merge them back into trunk. And yeah, I use tag for specific versions.
 
hah totally forgot i made this post, nice one for replies, and sorry to res an oldy :)

sort of muddled through it on my own, but just to clarify, when you merge from branch back into trunk, it seems to only be copying the changes from the branchs rep to my trunks working copy, do I then need to commit those changes again to the trunk?
 
Yeah, you do. Merge 'merges' two repos to your working copy, so you then have to commit your merged working copy back to Trunk.
 
Its also safest to merge the trunk into your branch before merging your branch back into the trunk so you catch any conflicts on your branch - this is assuming the trunk may have moved on from where you branched (multiple developers etc.).
 
keep your framework in it's own repo/branch/whatever, and set it as an external to your project.

branching is evil.. just commit to trunk. Flame on.
 
yeah i was going to say what happens when you have multiple branches and you want to commit to trunk and merge with all

ahh man this is giving me a headache lol
 
Mort said:
yeah i was going to say what happens when you have multiple branches and you want to commit to trunk and merge with all

ahh man this is giving me a headache lol
Click to expand...

Just merge them one by one, and manually merge anything that SVN can't deal with itself (which is unlikely if you're each working on different areas of the codebase).
 
You must log in or register to reply here.
Back
Top Bottom