[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: One Repository or Multiple?

From: Greg Stein <gstein_at_lyra.org>
Date: 2002-09-30 09:29:00 CEST

On Sat, Sep 28, 2002 at 10:56:15PM -0700, Blair Zajac wrote:
> Ben Gollmer wrote:
> > If you set up per-project mailing lists like I did, it's easy to use the
> > provided post-commit scripts to send mail on each commit if you have seperate
> > repos's for each project.
> >
> > If you've got multiple projects within one repository and want each one to
> > have it's own mailing list, be prepared for some script hacking.
> Not true. The supplied commit-email.pl script takes an optional regular
> expression command line argument which specifies which commits go to
> which email addresses.
> For example, in my repos, I have this in the post commit script:
> # Send an email out showing the differences in this commit.
> "$REPOS/hooks/commit-email.pl" "$REPOS" "$REV" \
> -m '^(branches|tags|trunk)/orca' orca-checkins@orcaware.com \
> -m '.*' blair@orcaware.com &
> See the commit-email.pl usage info for more info.

Passing all that stuff on the command line doesn't scale very well, so I'm
hoping to improve the situation with my mailer.py script (and remove some of
the inefficiencies of commit-email.pl).

Regarding the original question about multiple vs single repository:
originally, I was gung-ho on the multiple style, primarily for security
and data partitioning purposes. However, lately I realized that for (open
source setups), that there isn't much reason for strict data security. Since
everybody can read everything anyways...

So for some of the reasons that Greg Hudson provided (enable copy/move
between areas in the repos), I've lately tended towards single-repository


Greg Stein, http://www.lyra.org/
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Sep 30 09:29:00 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.