This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Issue Tracker Used? Git migration checklist.
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