How to structure your svn/svk repository

badaiaqrandista has asked for the wisdom of the Perl Monks concerning the following question:

Replies are listed 'Best First'.
Re: How to structure your svn/svk repository by biosysadmin (Deacon) on Oct 10, 2005 at 06:01 UTC
I can't comment on the structure without some more information - are those directories named after CPAN modules dependent on those modules? That's not how I would do it myself, but as long as you like it I suppose it's fine. Or maybe they're vendor distributions of the modules, versus your local modifications of those modules. If that's true, then it's a bad idea, for several reasons. Anyway, I prefer one big repository for all projects, with separate sub-structures for each project. It makes backing up the repository atomically much easier, but you can run into space issues. As always, TIMTOWDI. :)	[reply]
Re: How to structure your svn/svk repository by Tanktalus (Canon) on Oct 10, 2005 at 17:13 UTC
Personally, I put each into their own repository. Makes it easier to migrate to another repository in the future should I want to, e.g., SourceForge. Mind you, I also use cvs rather than svn/svk, which also makes it easier to migrate to SF :-)	[reply]
Re: How to structure your svn/svk repository by dragonchild (Archbishop) on Oct 10, 2005 at 17:21 UTC
`Repos Proj1 trunk lib t tags branches Proj2 trunk lib t tags branches ...` [download] This is how I structure my CPAN stuff, what OpenJSAN has migrated to (at my request), and how my employer structures both our OSS and work repositories. It's simply the easiest layout to work with, imho. Even if you never branch in most projects, you'll branch in one and you'll be happy for the consistent layout. Tagging should be done early and often, especially as tagging is O(1) in SVN. I generally tag every 4-10 commits in my CPAN projects. Anything more than that and you are probably looking at a complete rewrite, not a point release. As for migration - that's a non-issue. SVN can migrate to and from nearly every major SCM out there. Plus, how often are you really migrating from one SCM to another - isn't this just a straw man? My criteria for good software: Does it work? Can someone else come in, make a change, and be reasonably certain no bugs were introduced?	[reply] [d/l]
Re^2: How to structure your svn/svk repository by adrianh (Chancellor) on Oct 10, 2005 at 17:29 UTC
Tagging should be done early and often, especially as tagging is O(1) in SVN. I generally tag every 4-10 commits in my CPAN projects I'm curious what the point of a tag is if you're tagging this often? Or is it just a marker for "all tests pass"? Actually - I guess this depends on how often you commit... I tend to commit many times per-hour (pretty much every time I go from a test failing to all tests passing).	[reply]
Re^3: How to structure your svn/svk repository by dragonchild (Archbishop) on Oct 10, 2005 at 19:05 UTC
Lots of reasons. Once a feature has been added or a bug fixed, I'd like to tag that. Also, my point releases tend to be small, which means I shouldn't be having to add a lot of tests, which means 4-10 commits may very well be the 4-10 new tests I added and made pass. My criteria for good software: Does it work? Can someone else come in, make a change, and be reasonably certain no bugs were introduced?	[reply]