httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Richards <p.richa...@elsevier.co.uk>
Subject Re: read-only CVS acct on hyperreal?
Date Tue, 20 Feb 1996 20:35:04 GMT
>
> 
> But if it is read-only, they won't be "doing" anything that we care about,
> anyway.
> 
> What do you think it will break? Presumably all that can be broken is 
logging.
> Are checkouts/updates logged?

Yes, look at cvs history

>
> Hmmm, dunno about sup and ctm, but the short-term solutions are infinitely
> more painful than just doing "cvs update", which was why I suggested a 
readonly
> account in the first place.
> 
> If the "pserver" method is used, the "guest" account could be completely
> disabled for all uses except CVS (for example, set the password to "*" and
> give it a CVS password in .../CVSROOT/passwd).
>

If we're talking about providing access to development sources by
people who just want to keep in track with the latest fixes then
requiring them to install cvs is a bit of a chore. It's not the smallest
piece of software or the easiest to use. The support issues would
be considerable since there's too many toys for people to play with
even with read-only access. Read-only access isn't truly possible anyway,
all I could do is stop them commiting, the guest user would need write
access to the repository because of the status files and I'm not that
sure that the commit access file is checked for things like tagging and
so forth, I'd have to look into that. There's also the question of
being able to use cvs remotely in the first place, not everyone can.

Sup is a client server model using TCP so that makes it much more likely
to work through a firewall (most firewalls allow outgoing initiated
connections using TCP). It's also a single small binary which we could
supply for supported platforms easily enough. Its drawback is that it
needs a good connection since it sends the complete file back when
it sees a difference, although for something as small as Apache that
probably won't be a problem. 

Ctm is a "good" solution in that it sends out patches via mail (or you can
ftp them) and a client side program applies the patches. This is great
across modems since you just get small mail packets, you can filter these
directly to the client side program so you get automated updates every
X hours. It's drawback is that ctm was something developed specifically for
FreeBSD and would definately have to be ported but that should be simple
to BSDI.

I don't like the idea of using ssh and giving keys to specific "followers" of
the development code. I think the development sources should be freely
available to anyone who wants them whenever they want, with the caveat that
if they pick up development sources in between sanctioned releases they
understand what they're getting. This will create a much larger pool of
beta testers and a much quicker pick-up of new patches.

This obviously follows FreeBSD practice, this group may not agree.

Mime
View raw message