SVN: proper trunking/branching

Ok today i learnt that any team who wants to use Subversion as their serious source control system should never plant their project/solution source directly at the root of a repository.

Because any serious development team would want to mark a label for every official release. And since Subversion does not implement labelling, the (clever?) alternative to that is branching/tagging (revision mapping). The problem with tags is they become a "physical" directory in the repository, and if the root of the repository is already used as the root of the project source, then it becomes a recursively expanding structure for each subsequent tag/branch.

For example, a simple structure:

root/
>projectA
>projectB

Make a release 1.0.0 and tag it,

root/
>projectA
>projectB
>Release1.0.0

On a future release and tagging of 1.0.1,

root/
>projectA
>projectB
>Release1.0.0
>Release1.0.1

BUT, the "image" of Release1.0.1 will contain

root/
>projectA
>projectB
>Release1.0.0

and say another Release1.1.0 will contain

root/
>projectA
>projectB
>Release1.0.0
>Release1.0.1

Subsequent versions' tags will just increasingly contain all past tags. Now, I hope I have done something wrong to make this happen, and is actually not how it is meant to happen. If anybody can comment on how to correct this, I'd appreciate it, thanks.

What you should have done is this.

root/
> branches
>>> branch0.0.0.1
> tags
>>> Release1.0.0
>>> Release1.0.1
>>> Release1.1.0
> trunk
>>> current
>>>>>> projectA
>>>>>> projectB

How you can correct this is to redo the whole directory structure. Meaning, if you want to keep the releases, export (not checkout) everything, and recreate your directory structure, then import everything to a new repository or backup the old repository and clear everything before importing.

You will lose the "tags" and versioning, but your releases still are kept in proper order, unless you want to revert to a tag/version then that will be a problem. But you've got the backup repository, so you can work on that.

Furthermore, let me just reiterate again from my post long ago what the directory structure means.

branches contains tags where you want to work on a particular feature and code and still save it without affecting the main source code. Merging usually occurs with the main source code. Any editing here branches a new "revision history" seperate from the main code.

tags contains releases where you stamp a version of your code as a directory. No duplicate code is actually present in the repository. If you check out that Release1.0.1 in the directory, it's actually retrieving a particular revision history version.

trunk contains the current working main source code where most developer will work on. Note that trunk contains another directory called "current" or "MySolution", and it is advisable you do not put your root directory source code as trunk, else you'll encounter the same problems later.

icelava:

Ok today i learnt that any team who wants to use Subversion as their serious source control system should never plant their project/solution source directly at the root of a repository.

Because any serious development team would want to mark a label for every official release. And since Subversion does not implement labelling, the (clever?) alternative to that is branching/tagging (revision mapping). The problem with tags is they become a "physical" directory in the repository, and if the root of the repository is already used as the root of the project source, then it becomes a recursively expanding structure for each subsequent tag/branch.

For example, a simple structure:

root/
>projectA
>projectB

Make a release 1.0.0 and tag it,

root/
>projectA
>projectB
>Release1.0.0

On a future release and tagging of 1.0.1,

root/
>projectA
>projectB
>Release1.0.0
>Release1.0.1

BUT, the "image" of Release1.0.1 will contain

root/
>projectA
>projectB
>Release1.0.0

and say another Release1.1.0 will contain

root/
>projectA
>projectB
>Release1.0.0
>Release1.0.1

Subsequent versions' tags will just increasingly contain all past tags. Now, I hope I have done something wrong to make this happen, and is actually not how it is meant to happen. If anybody can comment on how to correct this, I'd appreciate it, thanks.

In other words, it is too late to change the structure in source control, not without major effort on my part to realign everything. Nope, have to live with it; not enough time, since I actually have to later reconsolidate this code base back into another VSS server - upon project's conclusion, only the VSS database will survive.