Issue Tracker Used? Git migration checklist.

Fred Cooke fred.cooke@gmail.com
Fri Oct 26 01:10:00 GMT 2012


Given such a single central master repository with no gatekeeper (bad
idea?) and many many committers, a hook would also be required to
prevent people from force pushing the golden copy. It'd  be much wiser
to have a shared repository that wasn't the public master, and the
golden copy that was pushed to by a trusted few from the shared one,
post review and perhaps clean up.

Presumably you realise that the hooks can not be automatically applied
to all clones and are on a per repo basis?

Great progress! I know that you, and others, have all of the gold
locked in their minds (and a thousand scattered aging posts to this
list), it'll be good to get it recorded in some sort of semi-formal
way.

Regards,

Fred. 3am, time for bed.

On Fri, Oct 26, 2012 at 2:12 AM, Joseph S. Myers
<joseph@codesourcery.com> wrote:
> On Fri, 26 Oct 2012, Fred Cooke wrote:
>
>> I agree that a single git repo for such shared files would (almost
>> certainly) be a good approach.
>>
>> Perhaps that migration could take place while CVS is still the master,
>> simply by creating it, with history, and removing the files from CVS,
>> replacing them with a script to clone/fetch/fast-forward from the
>> shared repo.
>
> I don't think the shared toplevel repository needs past history.  It isn't
> well-defined what the history is, anyway, given the complicated divergent
> history of these files in several different repositories.  (While git
> could represent such a divergent history, I don't think it really makes
> sense to try to do a precise conversion of it.)
>
> Removing shared files from CVS is a bad idea.  At each stage in any
> migration we should avoid as far as possible breaking things for existing
> users - existing scripts checking out, updating, etc. should continue to
> work, not have files vanish from checkouts.  For shared files this means
> leaving them in the src repository as long as any project still using the
> repository uses those files.  For substantive projects moving, this means
> leaving their files on the mainline of the src repository for at least a
> month or two after the move, to give people time to update their
> environments smoothly.
>
> Special scripts needed for checkouts etc. are something absolutely to be
> avoided; people should be able to work with each project in the most
> normal and natural way for projects using whatever version control system
> it is using, without needing any special scripts.
>
> For a shared toplevel repository, the steps might be:
>
> 1. Identify the exact set of files and directories to include (outlined in
> (a) in my message in March 2011).
>
> 2. Get consensus from binutils, GDB and GCC commmunities to have a shared
> repository as the master with all changes to those files only coming from
> there.
>
> 3. Get the files exactly in sync between the GCC and src repositories.
>
> 4. Where the files go in directories that are not fully shared, start them
> using separate ChangeLog files (e.g. ChangeLog.toplevel) to avoid those
> conflicting.
>
> 5. Prepare, and get consensus for, proposed pre-commit hook changes for
> the GCC and src repositories that disallow commits to the shared files and
> directories unless they contain some magic string indicating that they are
> updates from the master shared repository.  Such commits must only be
> disallowed on mainline; they must still be allowed on branches.
>
> 6. Prepare, and get consensus for, appropriate scripts to update the files
> automatically in the GCC and src repositories when commits are made to the
> master repository.
>
> 7. Prepare, and get consensus for, other hooks for the new repository
> (e.g. sending commit messages to the right place).
>
> 8. Prepare, and get consensus for, documentation for the new repository
> (its own web pages, and references on web pages of relevant projects).
>
> 9. Get overseers to set up an appropriate group for write access to the
> new repository, containing all active gcc or src committers.
>
> 10. Making sure the files are exactly in sync at this point, set up the
> new repository and the associated hooks and scripts to ensure commits to
> the shared files go via this repository.
>
> A conversion of binutils+gdb to git would of course require making the
> scripts mentioned under item 6 above handle updating the new binutils+gdb
> repository.  Likewise for any other component moving out of the shared
> repository.
>
> --
> Joseph S. Myers
> joseph@codesourcery.com



More information about the Binutils mailing list