Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

We have 3 Web Servers holding different stages in our development:

Development
Testing
Production

This is a mirror repository wise of the more general Trunk/Branch/Tag mode of things. I have developed a post-commit hook to automatically push commits to a publish folder on our repository server which then rsyncs the folder with the remote dev servers webroot.

Testing and production for purposes of this question can be considered to do the same thing.

To further slightly complicated things each project has 3 folders it may have material in:

coderoot
www
wwws

My current repository layout is

dev (trunk)
-coderoot
-www
-wwws
testing (branch)
-coderoot
-www
-wwws
production (tag)
-coderoot
-www
-wwws

With each projects repository having this layout. Is it possible to version each of the 9 subfolders as separate branches? Does this approach seem reasonable for any of you with a bit of subversion experience (using TortoiseSVN as the client)?

I'm new to this so I am open to ideas. I would like each subfolder to have it's own versioning timeline, but I realize this is probably not possible without a repository for each of the 9 folders, which would make browsing the structure in Tortoise a lot less convenient.

I apologize for the subjectivity of this question, but I am not sure where else to get intelligent points of view.

share|improve this question

1 Answer 1

up vote 0 down vote accepted

Well your definitely right, the subject is subjective but it is better advised not to do what you are thinking about above. Branches are designed and used mainly with the idea that many different developers can work on different parts of project but all need to sync back up again perfectly when a code merge is done at the end close to go live or staging and etc. When an application is getting ready to be released. From my experience what you suggest above would make it a nightmare tracking the changes of each folder as they would be unique branches with their own commits, revisions and logs and etc. Making them a repos' each would also complicate things further. The idea of tags, branches and trunks comes form the anatomy of a tree that each branch can serve a unique purpose and support smaller birds (junior developers) can nest on the smaller branches where as an eagle can roost on the higher more important branches (experienced developer) on the upper canopy of a tree. No branch is separate from the tree, all need to be able to be re-traced and code merged back into the trunk.

Tags are snapshots of releases, preferably of an up to date trunk. What you got set-up is bad practise. It's been a while since I last worked for a major software house but the last gambling organization I worked pretty much had all their repositories setup like that.

1 Reps = 1 project. n number of branches = n number of developers. n number of tags = n number of releases made from branches or trunk.

Tags can be created from a small release that has been checked in by a developer and wants it testing in a test area asap. Tags are also created from the trunk when the code is ready to be tested in a staging or testing environment when the application is close to being finalised.

My knowledge is limited but from what I saw at my previous employer this was the best way of doing things. Please understand that I am not talking up or down to you and that the tone of this post has not been intended to portray the former or the latter. I'm just trying to pick my brains on something I did ages ago.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.