This is the mail archive of the
mailing list for the GCC project.
Re: Moving C to its own directory (was Re: ObjC tree inlining)
- From: "Joseph S. Myers" <jsm28 at cam dot ac dot uk>
- To: Zack Weinberg <zack at codesourcery dot com>
- Cc: <gcc at gcc dot gnu dot org>
- Date: Wed, 21 Nov 2001 11:14:38 +0000 (GMT)
- Subject: Re: Moving C to its own directory (was Re: ObjC tree inlining)
On Tue, 20 Nov 2001, Zack Weinberg wrote:
> I'm a bit nervous about the number of weird libraries with unstable
> interfaces they want (neon, APR), and wonder if the client will wind
> up being as portable as we need it to be. They do seem aware of the
> issues, and they've got *BSD people on the team so at least it won't
> be all-the-world-is-Linux crap.
Also, is the BerkeleyDB file format used in repositories stable long-term
between BerkeleyDB releases?
Some obvious questions that the "Subversion for CVS Users" page doesn't
* What's the equivalent of cvs -z<n> (link compression)? In general, how
do the bandwidth-efficiency of checkouts and updates compare between CVS
* What's the Subversion equivalent of CVS-over-SSH?
* What's the Subversion equivalent of cvsweb, and is there one available
in which the Subversion sources and their history can be browsed?
> When they get to beta I may do some trial conversions of our existing
> repository, time permitting.
It ought to be possible to teach the conversion program about the idiom of
cvs remove / cvs add to rename files (allowing for complications such as
the file having changed when it was renamed and the file having been
renamed at different times on different branches), given a list of (old
name, new name) pairs (which could be constructed, mostly completely, when
necessary by examining the current Attics). Given this there's no need to
hold off moving files on the basis that Subversion will make it easier
(and in general I think holding off work on the basis that some other
piece of software (independent of GCC) will, through code that hasn't yet
been written or stabilized, make things easier at some future point, is a
bad idea - when Subversion is in fact ready, not when it's predicted to
be ready, we can then deal with the conversion).
Joseph S. Myers