Versioning in SVN

Question

I have a situation where I would like to track versions of some of the folders in my project. Let's assume the following is my SVN structure

branch name let's say is BRANCH. pattern of directories - [TopFolder/SubFolder1/SubFolder2..]

A/a1/a2/a3
B
C
D
E
F
G/g1
E/e1/e2
F

I want to make sure that when I run my tool which let's say resides in directory F - it should pick up code from G, E & C. And it should not pick up the latest code, but a blessed QA code ie a SVN revision for each of the folder.

One solution is to track the svn revisions of G, E & C which are QA blessed and then svn up them to that revision before running the tool.

Another solution is that
1. I create a branch BRANCH_1 which has all the things QA blessed.
2. I run the tool from BRANCH_1. No need to svn up anything since the latest is greatest.
3. I make code changes to BRANCH as I feel like
4. Once BRANCH has been QA'ed, I sync BRANCH_1 with BRANCH. BRANCH_1 would not be usable while the sync is in process.

I want to hear few other ideas which can be cleaner and more robust? May be one which doesn't have you create branches now and then.

Answer 1

I want to make sure that when I run my tool which let's say resides in directory F - it should pick up code from G, E & C. And it should not pick up the latest code - but a blessed QA code.

I have a very difficult time understanding your question. However, you might want to use svn:externals to point your G, E, and C directories into your F directory. You can (and in fact you should) point your svn:external to a particular revision of the other directories. For example, use the -r option to specify a particular revision or point to a tag.

Would this help you?

Answer 2

I see a couple straightforward ways to do this with branches.

The first idea, is to keep two long-standing branches. You'd have a "dev" or "trunk" where you developers work, and you'd have a "release" or "approved" or something where QA works. Periodically QA will merge changes into their branch, test them, and if the test passes, commit. Then only QA-approved changes make it to the "release" branch, while development proceeds as normal on trunk. So, you script can always just pull the latest "release" branch code.

The second idea, is to have a "clean trunk" process. Every change developers make is done on a new branch. Before any change gets merged to trunk, QA must test and approve the change. Thus, your script can always just pull the latest "trunk" code. This can cause a much slower development cycle, however, and may result in a large number of merges increasing chances to introduce errors. So unless you have other reasons to prefer this process (required peer reviews before committing to trunk, for example) it may not be efficient for your team.