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 _______________________________________________ Gnustep-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnustep-dev
