This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: SVN for src, status?
On Tue, May 12, 2009 at 10:38:50PM +0000, Joseph S. Myers wrote:
>On Tue, 12 May 2009, Segher Boessenkool wrote:
>>harder though. So my vote is to move to either SVN or git ASAP; I
>>don't care which one.
>
>My vote is to do nothing ASAP, but for the advocates of different
>schemes to work out detailed designs for the various options for single
>repository and full checkouts (changes to how you configure to build
>only a subset of components) / single repository and partial checkouts
>(possible with SVN, not with git) / multiple repositories and automatic
>merging of shared files between them and once there are detailed
>designs produce trial conversions (likely several trial conversions
>over the course of a few months) of the repository and all associated
>scripts run on commit etc. for people to play with. Trial conversions
>might just be for a single option, or for more than one option
>depending on feelings about the different options. If Red Hat people
>can obtain the release of the pre-sourceware history, then I'm sure Ian
>can help with including it in the trial conversions.
>
>Anything requiring special scripts for checkout / commit / push needs
>to include those scripts in the trial conversions (and the scripts need
>to cover both read-only and write-access checkouts, and switching
>between the two).
>
>I will observe we have great difficulty keeping files in sync between
>GCC and src with just two repositories and shared files often spend
>months out of sync after a change is applied in one place only, and
>suggest that any multiple-repository scheme needs fully automatic
>merging of changes to shared files so that it is made impossible (by
>hooks preventing commits / pushes to the wrong place, for example) for
>someone accidentally to get the master versions of the shared files out
>of sync. (Of course changes to the files on branches should be allowed
>without requiring them to be in sync with some other repository, just
>not on the mainline of development.)
Maybe the files that we have difficulty keeping in sync should really be
in a repository all by themselves. I know that's tricky with top level
configure files but maybe they could be in a directory by themselves,
symlinked one level up or something.
cgf