The only thing preventing me from going with a single repository is the
global revision number. If I start with one project and observe the
number increasing sequentially, no problem. But when I add a new
project and start where the last revision number left off (plus one of
course) then it just seems strange. I was hoping to use the revision
numbers in my application's version number (1.0.56 or 1.1.234) or
something like that. How else does one keep track of that if not by the
revision number?
> -----Original Message-----
> From: cmpilato@virt16g.secure-wi.com [mailto:cmpilato@virt16g.secure-
> wi.com] On Behalf Of C. Michael Pilato
> Sent: Thursday, March 25, 2004 10:27 AM
> To: bbeaudet@efficiencylab.com
> Cc: users@subversion.tigris.org
> Subject: Re: Repository Layout - One Vs. Many
>
> "Brian Beaudet" <bbeaudet@efficiencylab.com> writes:
>
> > I'm looking for suggestions on my repo layout. My company has
several
> > developers/non-developers (documents, QA, testing, etc.) who will be
> > user Subversion for version control. We work on many projects at
one
> > time. I'm considering setting up many repositories one for each
> > project. I was wondering what the experience of the user community
out
> > there is on this type of layout. I'll be doing the admin so it's up
to
> > me to determine the best layout.
>
> I routinely use both the many-projects-in-one and the
> one-project-per-repos setup. There are obviously pros and cons to
> both. If you expect to ever need to copy stuff between projects
> (while maintaining history), the one-repos approach is necessary.
> Multiple repositories means maintaining multiple sets of hook scripts,
> too. And if a future version of Subversion requires a dump/load
> cycle, you have N repositories to dump and load instead of one giant
> one.
>
> That said, many smaller repositories lessens the side-effect of some
> breakage -- if some event causes the repository to lock up and need
> recovery, at least only one repository is affected. Also, because the
> many repos will be smaller than a single shared one, your backup and
> restore granularity is easier to deal with. As for the many sets of
> hook scripts, I suppose you could make each repo's hooks just be dumb
> wrappers around some common hook-scripts shared by all repositories.
>
> You should also consider the auth question. Depending on your access
> method and auth setup, your may find one or the other of the layouts
> cumbersome.
>
> Keep in mind, too, that you could use a mixed approach -- similar
> projects can share a repos. You know, a sort of grouping effect.
>
> Finally, the Subversion book authors do recommend that *regardless* of
> the choice of many versus one repos, make it such that beneath each
> "project root" there are "trunk", "tags", and "branches" directories.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Mar 25 16:35:03 2004