Re: Issue Tracker Used? Git migration checklist.

[Fred Cooke <fred dot cooke at gmail dot com>]

Thank you!!

So then the first step, and likely the most difficult, is to bring all
of the relevant communities (that necessarily share files) together
and gain agreement on how to handle that resource. Perhaps some
sharing that is not necessary and could gain (rather than lose) from
divergence could be identified too? Perhaps not.

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.

Fact remains, SOMETHING needs to actually happen or it'll never be completed.

What the first something is, I don't know.

Fred.

On Fri, Oct 26, 2012 at 12:46 AM, Joseph S. Myers
<joseph@codesourcery.com> wrote:
> On Fri, 26 Oct 2012, Fred Cooke wrote:
>
>> Exactly how many distinct projects are in the top level of the tree?
>
> See my message from March 2011 enumerating the logical divisions from (a)
> to (i), and the subsequent discussion concluding that (h) is really three
> separate independent projects.
>
> Note that I propose that *each project should choose independently whether
> and when to move from the shared tree, and what version control system to
> use if moving from it*.
>
>> And how many of them have cross dependencies at a source level?
>
> Various components use various subsets of the toplevel code (which would
> therefore be present in multiple repositories).  It may be a good idea to
> set up the (a) master repository for shared toplevel files first, to avoid
> even worse divergence than we have at present with files being
> independently modified in the GCC and src repositories - if there are
> three, or ten, separate repositories sharing this code, a better
> discipline for modifications to it may be needed.
>
> My message discusses what actually depends at all (or not) on the shared
> files in various cases.
>
>> And in reply to the more recent one, are you suggesting that the
>> current binutils git repo is incomplete/broken and that a new export
>> will need/want to be done with a new email mapping, etc?
>
> I am suggesting that a shared binutils+gdb repository will be the best
> approach for keeping BFD in sync automatically while ensuring that all the
> normal git commands work exactly as expected for tagging, branching,
> commits etc. - and that once everything is ready, we should create a clean
> conversion of the existing history of exactly the directories that are
> then determined to be relevant.
>
> Ideally the conversion would include the history of GDB from before it was
> developed in a public repository but I have not heard of any progress on
> getting that released.
>
> --
> Joseph S. Myers
> joseph@codesourcery.com