I wanted to check if I can still manage to mail to the dev list with
this address, or if I need to start doing some quirks somewhere to
make it happen. But instead of mailing pure noise, I snuck in a bit of
signal as well.
I've always found the example repository layout - eg. trunk, branches,
tags - to be... well, contorted. The things I dislike with it are:
* Separation between trunk, branches and tags.
This is a very minor point, based mostly on personal feeling. Since
branches and tags are just copies, and the trunk is no holier than any
branch, I've always felt that separating everything strictly into
three categories 'the' trunk, branches or tags was
arbitrary. Obviously it helps the person coming from a version control
system with specifically branches and tags to feel at home - but I am
not sure if it actually helps them understanding what is going on that
much.
* Differences in directory hierarchy level.
It is ofcourse obvious that the trunk directory contains the actual
project files - and that branches and tags both contain a set of
directories each of which is a separate branch or tag. But
nevertheless, I feel this difference in nesting levels mildly
unnerving.
* Non-descriptive working copy names.
With the repository layout as is, the default name for the working
copy ends up being just "trunk". And the names of the other
directories are not much better - "1.0.x", "issue-123-dev",
"0.10". They may be okay if the parent directory where they reside on
the filesystem has a descriptive name - but even so, they sort oddly
if there are any other files in the directory and just plain look
weird. So most everyone will just supply their own working copy names
- like just about every example everywhere does.
* English language derived.
Ofcourse in software development in general, there's bound to be quite
a bunch of englishms around. And it would be very irreasonable to
expect 'HEAD' to be changed to something else. But these are both
unnecessary and difficult englishms. The distinction between 'branchs'
and 'branches' might not be too easy to see.
These problems struck me the already at the time I was creating my
very first Subversion repository. So, like advised, I came up with my
own scheme, which goes roughly like this:
* Every directory starts with the project name.
* Every directory where changes are made (eg. branch) ends in "-dev".
* The trunk of development is "<project>-dev".
* The version branches are "<project>-<version>-dev".
* The version tags are of form "<project>-<version>".
As an example, what the subversion repository would look like:
New: Old:
/ /
svn-dev/ trunk/
svn-1.0-dev/ branches/1.0.x/
svn-issue-1601-dev/ branches/issue-1601-dev/
svn-pluggable-db-dev/ branches/pluggable-db/
svn-1.0.0/ tags/1.0.0/
svn-1.0.0-beta1/ tags/1.0.0-beta1/
svn-0.37.0/ tags/0.37.0/
And also, as an example from my personal projects:
/
project-dev/ Trunk of development
project-feat-dev/ New feature development
project-rel1/ Release 1
project-cvs/ Latest CVS-import of upstream
project-cvs-2004-02-12/ CVS-import from a date
project-cvs-2003-12-21/ Earlier CVS-import from a date
Obviously the same transformations that are suggested for the example
layout work for this layout as well - if there are several projects in
the repository a layout like this can be suitable:
/
utils/
calc/
calc-dev/
calc-some-branch-dev/
calc-some-tag/
calendar/
calendar-dev/
calendar-some-branch-dev/
calendar-some-tag/
office/
spreadsheet/
spreadsheet-dev/
spreadsheet-some-branch-dev/
spreadsheet-some-tag/
I have used this repository layout, with tiny variations, for
everything I have kept in Subversion and it has served me well.
So, in case people haven't thought of any reasonable alternatives to
the trunk, branches, tags - I thought could present my version. And
more importantly to help people have an open mind towards any
solutions that might work even better for them.
And even more importantly - to help me diagnose connection issues by
writing and idle chatter like mail :-)
Huggle each other,
-- Naked
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Mar 12 00:45:59 2004