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

RE: svn commit: rev 2717 - / clients clients/rapidsvn

From: Sander Striker <striker_at_apache.org>
Date: 2002-07-26 17:08:34 CEST

> From: Karl Fogel [mailto:kfogel@newton.ch.collab.net]
> Sent: 26 July 2002 16:14

> gstein@tigris.org writes:
> > Added:
> > clients/
> > clients/rapidsvn/
> > clients/rapidsvn/branches/
> > clients/rapidsvn/tags/
> > clients/rapidsvn/trunk/
> > Log:
> > Set up a /clients area, and initially populate it with dirs for the
> > rapidsvn project.
> Is there a reason to put this in "/clients/rapidsvn", instead of in
> "/trunk/subversion/clients/rapidsvn/"? I thought we'd agreed on the
> latter convention...

Because that would mean we support one client effort over another
by having it in the standard distribution. That wouldn't be fair
to the projects that aren't in the svn repos.

We discussed this quickly on irc yesterday and forgot to post the
conclusions. We == gstein, sussman, xela, me and others.

> One side-effect of this change is that the COMMITTERS file now lives
> at the top level, which is a bit inconvenient because hardly anyone
> keeps a copy of "/" checked out -- who wants all those branches and
> tags locally? Most people just keep a working copy of "/trunk".
> Now I need to add `fmatias' to the COMMITTERS file, and in order to do
> it I'll have to check out "/" nonrecursively, which (see issue #695)
> will result in a horked working copy. Probably I'll be able to commit
> COMMITTERS, but it's still no fun to have a known broken working copy
> around :-(.
> Can we reconsider this arrangement?
> -Karl

I would just like COMMITTERS to go back to /trunk and have a stripped
down COMMITTERS file in /clients, containing the client developers.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jul 26 16:59:12 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.