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

projects in one repos at svn.collab.net (was: svn commit: rev 2717 - / clients clients/rapidsvn)

From: Greg Stein <gstein_at_lyra.org>
Date: 2002-07-31 03:01:56 CEST

On Fri, Jul 26, 2002 at 05:34:31PM -0400, Garrett Rooney wrote:
> On Fri, Jul 26, 2002 at 11:35:08PM +0200, Sander Striker wrote:
> > The second point is that when the number of client project grows,
> > so will our distribution. Personally I would only like to see the
> > cmdline client in our distro. And yes, that means we should move
> > the win32 com code to /clients aswell.
> +1
> the core distribution should be composed of the libraries and a cross
> platform command line client. anything else (web based repository
> viewers, gui clients, etc) should be distributed in separate tarballs.


> as to the question of 'should they go in the main repository', i'm
> ambivalent. if the collab.net people are ok with it, since they're
> running the server, i say put them in /clients.

Actually, my thought process was more that all the projects should just go
into one big-ass SVN repository. In the past, I've advocated one repos per
project, but that was mostly for security purposes (read and/or write). But
for *open source* projects, you'll never bother with denying read access.
And we definitely have write-access controls to be able to do per-project
access control (it is simply more difficult to do well with Apache's built
in authz stuff).

One of the benefits of a "mother" repository that contains everything is
sharing bits across the projects. You can copy/move portions around the
projects as you reorganize or set the stuff up. And that would retain
history, whereas multiple repositories would not.


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 Wed Jul 31 02:59:15 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.