1

I'm thinking of moving to SVN from mercurial because it seems simpler to maintain and more people have an SVN client than a mercurial client available. However I have a question regarding file structure -

I understand that the typical proper SVN structure goes:

/trunk
..../current version files here

/branch
..../bugfix
..../newfeature
..../branch3
..../branchN

/tag
..../version 1.0
..../version 2.0
..../version n.n

My question is how does this factor into multiple OSes? My software currently has separate mercurial repositories for the GUI/CLI versions of my software for each OS since you can't only checkout a directory in mercurial. However, I understand you can in SVN. Would the structure look like:

/Windows (or Linux, or whatever)

/trunk
..../CLI
...../current version files here
..../GUI
...../current version files here

/branch
..../CLI
...../bugfix
...../newfeature
...../branch3
...../branchN
..../GUI
...../bugfix
...../newfeature
...../branch3
...../branchN

/tag
..../CLI
...../version 1.0
...../version 2.0
...../version n.n
..../GUI
...../version 1.0
...../version 2.0
...../version n.n

Or am I making this far too complicated? Would you recommend storing the GUI version in a separate repository? Also in which of these typical directories are precompiled executables stored?

I understand these questions may seem novice, but the truth is I'm completely new to SVN. Thank you for your help!

Dr.McNinja
  • 455
  • 1
  • 6
  • 15

1 Answers1

1

I have been using SVN for only about 3 or 4 years now and what you have looks pretty good to me, I wouldn't store the GUI version in a separate repo. At my work we have all of our projects under one repo, just different folders and this works because as you stated you can check out whatever folders you want.

Also there are some people out there that argue that you shouldnt store binary data (such as precompiled executables) in an SVN repo simply because it will bloat the repo as it cannot be diffed with the previous version such like text can. This is more or less the unwritten policy at my work. At home on my personal SVN I will check in important executables or library files that I know wont change regularly, just so they are there when I need them. I am not worried about bloat, and being able to step back through the other version of the exe is kinda cool sometimes to see the progression.

As far as branches and tags go, I have never used them. I know I probably should, but most of my projects are 'proof of concept' anyways and so my main trunk is really all I build to. I basically use SVN as for a very nice backup and timeline tool. But I prob should start using tags and branches.

CenterOrbit
  • 6,446
  • 1
  • 28
  • 34
  • Thank you for the reply, I really appreciate the input from personal experience. I'm also thinking about just making the GUI command line invokable and remove the CLI version altogether. Not storing binary files in the SVN makes complete sense. I have FTP space for that after all. Thanks again!! – Dr.McNinja May 23 '11 at 04:21
  • Your welcome, I personally like the idea of making the GUI command line invokable. It seems like a more versatile solution and more elegant in a way. But its your project, do as you would like ;) – CenterOrbit May 23 '11 at 16:51