This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]