Re: Proposal: Subversion Migration

[Andrew Ruder]

On Sun, Oct 23, 2005 at 01:25:20PM +0200, Markus Hitter wrote:
> Subversion doesn't enforce any directory layout at all. Tags,  
> branches and copies are all "cheap" and are all the same: a bunch of  
> references in a new directory to what you have copied/tagged/ 
> branched. To me, it's unclear why there's still made a difference  
> between tags and branches[1], but that's how the Subversion book  
> recommends it and it seems to be widely accepted.

It is mostly just a namespace/convention issue.  If I look through the
tags directory, I should see only unchanging things marking the actual
1.0 release or the actual 1.1 release or some marker before some major
changes are merged in, etc...  I know that if I check those out I won't
be needing to run svn update from time to time.  The branches/ directory
would be similar but I could assume that they are still being worked on
or will have been actively developed in the past.  There is no reason to
have them, just a general convention which seems to have worked well
over the years.

> Unlike CVS, Subversion numbers versions throughout the whole  
> repository. A bunch of files checked out have always the same  
> version; files get higher version numbers even without being changed.  
> As a result, one should tend to make small repositories, i.e. one for  
> each app, one for each tool, one for each lib.

You can, but svn does a good job of not making the revision #'s a pain.
It is kind of weird to see the history on gorm and see that it changed
at revision 11500 and 11420 and nothing inbetween, but there is no
reason why that's an overly bad thing, imo.  The bad thing about having
small repositories is that you have to be very sure they will never have
overlap (i.e. make sure that you'll never have to reorganize across
repository boundaries) or you'll have yourself a mess for sure :)


-- 
Andrew Ruder
http://www.aeruder.net