> From: Karl Fogel [mailto:kfogel@newton.ch.collab.net]
> Sent: 26 July 2002 21:54
> "Sander Striker" <striker@apache.org> writes:
> > 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.
>
> Er, okay, but...
>
> This still doesn't make much sense to me.
>
> Projects that "aren't in the svn repos" are neither in
> /trunk/subversion/clients/ nor in /clients -- they're in whatever
> repos their author keeps them in. So if we've been disfavoring
> certain clients by having them outside the repos (a questionable
> assertion, since it was more likely the client author's choice than
> ours), we're *still* disfavoring those clients, because this
> rearrangement does nothing to bring them into the repos.
Sorry, I meant to say "in the standard distribution" instead of
"in the svn repos". When a client is in the standard distribution
it looks like we support it (and favor it as a client since we
bundle it).
> If a client is in our repos at all, I see no problem having it in
> trunk, such that it's in the standard distribution. If the thing
> builds, then great. If not, then it just doesn't get built as part of
> the standard build process. If something's not ready for prime time,
> the documentation can just say so.
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.
> If our goal is to solve the endorsement problem, by deciding to
> endorse nothing, then this is not a solution. If having something in
> our repository at all implies endorsement, then we're *still*
> endorsing these clients under this new arrangement. And if having
> something in our repos does not imply endorsement, then we might as
> well keep them in /trunk/.../.
>
> If we just want to provide generic repository hosting services for
> people writing SVN clients, then that's wonderful, but shouldn't it be
> a different physical repository? (Perhaps even one repository per
> client, but at the very least a different repos with a separate auth
> structure?)
The auth structure isn't a problem, as gstein has pointed out several
times in the past. We have/are a version control system. Bogus/malicious
commits will simply be rolled back.
> I'm not adamantly opposed to the new arrangement to the point of
> vetoing it or anything like that. But I don't understand the point --
> it doesn't seem to serve its goals very well. I think it's just going
> to be confusing. Heck, I'm already confused, as you can tell :-).
*grin* I hope this clarifies it a bit.
> -Karl
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jul 26 23:25:37 2002