source mgt. requirements solicitation
Joseph S. Myers
jsm28@cam.ac.uk
Mon Dec 9 17:10:00 GMT 2002
On Mon, 9 Dec 2002, Walter Landry wrote:
> Anonymous access requires for HTTP + WebDAV (no DeltaV). However, the
> set of WebDAV commands needed are much smaller than what subversion
> needs. It just needs whatever anonymous ftp has that http doesn't (I
> believe PROPFIND is one). In particular, you can run a server using
> apache 1.3.
I'm sure some "transparent" proxies will fail to pass even that (though
WebDAV may be better supported by them than DeltaV). This is similar to
Zack's first point - just as any new system must be no less portable to
running on different systems, it must be no less portable to working
through networks restricted in different ways.
> I have a feeling that you are thinking of how CVS handles things, with
> a centralized server. Part of the whole point of arch is that there
> is no centralized server. So, for example, I can develop arch
> independently of whether Tom thinks that I am worthy enough to do so.
> I can screw up my archive as much as I want (and I have), and Tom can
> be blissfully unaware. Easy merging is what makes this possible.
>
> So you don't, in general, have a repository that is writeable by more
> than one person.
For GCC there clearly needs to be some server that has the mainline of
development we advertise on our web pages for users, from which release
branches are made, which has some vague notions of the machine being
securely maintained, having adequate bandwidth, having some backup
procedure, having maintainers for the server keeping it up reliably,
having a reasonable expectation that the development lines in there will
still be available in 20 years' time when current developers have lost
interest. (gcc.gnu.org presents a remarkably good impression of this to
the outside world, considering how it operates purely by volunteer
effort.)
There may be many other servers - private and public - but some server
provides the line of development that gets branched into new releases, and
inevitably multiple people may write to that line. (I'm also presuming -
see <http://gcc.gnu.org/ml/gcc/2002-12/msg00436.html> - that all the
developments in any third party repository that get discussed on the lists
should be mirrored into this main one to give some hope of long term
survival and availability. In developing GCC with list archives and
version control we are simultaneously acting as curators of the history of
GCC development, which means attempting to preserve that history for
posterity (a period beyond the involvement of any one individual).)
--
Joseph S. Myers
jsm28@cam.ac.uk
More information about the Gcc
mailing list