Currently we've got a directory structure that looks like this

+Inhouse App A
+Inhouse App B
+Core files for inhouse app B
+Inhouse App C
+Something that never came to fruition
+Forgotten Server Project A
+Forgotten Common Files A
+Authentication Server
+Update Server
+Main product Version 5.5
-----+[Our Awesome Controls]
-----+[3rd party control 1]
-----+[3rd party control 2]
-----+[3rd party control 3]
-----+[Util 1]
-----+[Util 2]
-----+[Util N-1]
-----+[Util N]
+Main product Version 6.1
+Main product Version 6.2
+Fingerprint SDK

Obviously, I am covering up some ugliness of this beauty. I've got an install of VisualSVN to replace Visual 'shall not be named' and I get to the point where it says, trunk, branch and something else. and from some other posts here and on SO, I know vaguely what those are for.

My question is what do I do to translate my existing file structure to the source control structure. We've give up hope of doing any meaningful import.

I've tried just going head first into this already, but I feel I'm missing some key concept.

For instance, should all these things be in the same repo? If they're not in the same repository, how are they going to find the files shared between the projects?

  • ...Main product version 6.1 and 6.2 have the same directories (and then some) as version 5.5, they've been omitted for brevity – Peter Turner Sep 27 '11 at 20:14

First of all, the structure of a Subversion repo is just a directory tree. The use of 'trunk', 'branches' and 'tags' directories is just a community convention. As a any convention is better for you to stick to it, but not mandatory. That said, I use to have ONE repository for an application and inside this repo, the classic structure 'trunk', 'branches' and 'tags'. But if the application is big enough or have a bunch of modules you have two alternatives:

A: (For shared versions among modules)

trunk (module-A, module-B, module...)

B: (Versions will go independently for each module)

module-A (trunk, branches, tags); module-B (trunk, branches, tags)

The second alternative could be implemented using a single repository or multiple ones, on the SVN Book (link below) you have a description of each one and their benefits.

If you are not familiar with the usage of directories 'trunk', 'branches' and 'tags', here you have a brief description, but please refer to the SVN Book, and look for "Strategies for Repository Deployment" and "Recommended Repository Layout" sections.

  • trunk: “main line” of development
  • branches: divergent copies of development lines
  • tags: named, stable snapshots of a particular line of development

How do I use them? - The first project structure was uploaded to the trunk. - Every time a new requirement or project comes we copy the trunk content into a new branch (with a representing name). - We work on that branch until completion of UATs (User Acceptance Testing). - After that, we reintegrate the branch with the trunk (merge). Note: if more than one branch is going to be released to production you have to do all merges before and ideally test the integration of all changes, using the trunk code. - Finally we create a tag, to mark the release of this version to the production environment. Note: all tags are read only, no one on the team can change a tag after its creation. This simple rule ensures that you can go to a known stable version of the code if the some problem occurs.

In summary (and here are your key concepts):

  • Read the SVN Book.
  • Understand the basics of subversion
  • Become familiar with all different projects structres alternatives and choose the one that better fit your needs.
  • Become familiar with all different branching models, use the matching one depending on the work to do (a bug fix, a request for change, a long project, etc.).
  • Understand what trunk, branches and tags are for, specially the last one.
  • Understand what is a working copy, a repository, a revision, the cheap copy concept
  • Remember not to version your binaries, only your sources. I made this clarification because of your actual layout you have things named "DLLxxx", so I'm assuming they are binaries (.dll files).

After the implementation, if you have troubles getting your partners to work with the tool, here is a possible reason of that behavior: Why developers don’t use a Version Control System (CVS, SVN, Git, Hg, ...)?, please leave your comments or experiences on getting a team on using a versioning tool.

|improve this answer|||||
  • +1: read the SVN book. Not in the sense "do your homework" but more "you won't waste your time, and maybe you will be gratful after" – mouviciel Sep 28 '11 at 8:28
  • Yeah, DLLXXX is pretty much how we name our binaries, but the XXX doesn't mean anything about the version there, it's just a cryptic way of naming binaries that arose for no particular reason. – Peter Turner Sep 28 '11 at 14:40

There's no intrinsic reason you can't stick with your current directory structure. Dump all of this within trunk/, and you're good to go. You won't necessarily get all of the benefits that might potentially be possible if you had separate branches for v5.5, 6.0 and 6.1, but based on what you're describing, I doubt it is even possible to gain those benefits at this point. Gaining those benefits requires non-trivial workflow changes, and it might be easier to first gain traction with VCS as a general concept that includes tracking, and introduce branches-per-version later on if it makes sense with your workflow.

|improve this answer|||||
  • Yes, just dumping it in might be a good start. For svn the repository is just a tree, so you might restructure the layout in the long run. Doing it all at once usually is a BIIGG project as you have to adopt your whole build environment etc. I'd still read the svn book and get used to branch handling beforehand. – johannes Sep 28 '11 at 17:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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