public inbox for cgen@sourceware.org
 help / color / mirror / Atom feed
* Converting CGEN from CVS to git
@ 2019-01-31 19:50 Andrew Burgess
  2019-02-02  9:35 ` Jose E. Marchesi
  2019-02-03 16:30 ` Frank Ch. Eigler
  0 siblings, 2 replies; 15+ messages in thread
From: Andrew Burgess @ 2019-01-31 19:50 UTC (permalink / raw)
  To: cgen

I would like to discuss the idea of converting CGEN from CVS to git.

Motivation
==========

I have been working with CGEN off and on for the last 8 years, and
though I haven't posted any fixes upstream in that time, I do have a
set of fixes locally that I would like to try an upstream over the
next year.

Obviously, moving from CVS to git isn't a requirement for working on
this project, but hopefully we can all agree that moving out of CVS
makes development easier, and git seems like the obvious choice.

Summary
=======

I've done some initial work on a git conversion.  My converted
repository can be found here:

  git@github.com:T-J-Teru/cgen.git

And the scripts I use to perform the conversion, along with a detailed
README that lists all of the validation I have done on the conversion
(summary below) can be found here:

  git@github.com:T-J-Teru/cgen-2-git.git

History of the CGEN Repository
==============================

I think most people reading this will already know this history.  But,
by laying out my understanding you'll be able to correct me if it
turns out what I think I know is actually wrong.

In the past many tools hosted on sourceware.org existed in a single
large CVS repository and made use of CVS's module system to allow a
subset of subdirectories to be checked out using a single name.

So, GDB existed in this repository, and a request to checkout 'gdb'
would give you the top-level directory, the gdb subdirectory, and also
the bfd subdirectory, the libiberty subdirectory, the opcodes
subdirectory, and so on.

The binutils project was also in this CVS repository, checking out
'binutils' would give you the same top-level directory as for 'gdb',
but then the gas, ld, bfd, libiberty, opcodes, etc subdirectories.
Notice that some subdirectories are common to both projects, while
others are specific to a single project.

The CGEN project was also in this CVS repository, its main components
are in the 'cgen' subdirectory, but a number of other subdirectories
are also included in a 'cgen' checkout.

If a user had checked out the binutils project, and then wanted to
regenerate the CGEN components, they could simply ask CVS to checkout
the 'cgen' project in the same location, and any additional
subdirectories required for the 'cgen' project would be fetched from the
server.

Then binutils and gdb moved from CVS to git.

We now have the binutils and gdb project in a single shared git
repository, leaving CGEN behind in CVS.

So, until a few months ago if a user wanted to rebuild the CGEN
components the only way was to checkout binutils-gdb from git, then
checkout CGEN from cvs to a separate location and copy the cgen
subdirectory from the cvs checkout into the git repository.  After
this the user can continue to use CGEN.

A few months ago I improved on this by changing binutils-gdb so that
it could make use of CGEN in a separate location, avoiding the need to
copy the cgen subdirectory around.  This was done in this patch series:

  https://sourceware.org/ml/gdb-patches/2018-11/msg00061.html

Now the user only need checkout binutils-gdb to one location, checkout
CGEN to a separate location, configure binutils-gdb to know where CGEN
is after which they can regenerate the CGEN parts of binutils-gdb as
needed.

It is now possible to maintain a clean separation between binutils-gdb
and CGEN during development.

Conversion Design
=================

The observation that in order to regenerate the CGEN components, the
only part of the cgen CVS module that needed to be copied into the
binutils-gdb was the cgen/ subdirectory was the reasoning behind one
big choice I made, that is:

    Only the cgen subdirectory of the current cgen CVS module would be
    included in the new git repository.  Everything else is unneeded
    clutter, and should be discarded.

As CGEN is not very active right now I made the choice to discard
almost all branches when converting.  My assumption is that the old
CVS module will remain available in read only mode, so if an
historical branch is needed then it can always be recovered later.
The only branches I kept are the main development branch (now master)
and the 1.1 release branch (called cgen-1_1-branch).

Conversion Status
=================

After the conversion there are only two branches in the CGEN git
repository, 'cgen-1_1-branch' and 'master'.

The only tags are 'cgen-1-0', 'cgen-1-1', and a set of tags matching
the pattern 'cgen-snapshot-*'.

The 'cgen-1-1' tag was added during the conversion, and matches what
was released as CGEN version 1.1.  This is simply the tip of the
cgen-1_1-branch.

Other than cgen-1-1 (which doesn't exist in CVS) every branch and tag
has been manually checked out in CVS and git and compared, and in all
cases the content matched.

The release tags cgen-1-0 and cgen-1-1 have been compared to the
contents of the release tar files, no differences were found.

I have then used the latest version from CVS, and the HEAD of master
from git to regenerate all of the CGEN created files in the
binutils-gdb/opcodes subdirectory, and in the binutils-gdb/sim
subdirectory for targets that use CGEN.  In all cases the files
regenerated from CVS and git were identical.

Additionally, I checked out the sid project and confirmed, again using
the latest from CVS and HEAD of master from git, that the regenerated
files matched.

I would be interested to hear any additional ideas for testing that I
should perform.

Other Infrastructure
====================

Until June 2018, a new snapshot tag was generated every month.  After
June this stopped.  I don't have visibility of the script performing
this tagging, but this script would need to be updated to work with a
git repository (if we wanted the tagging back again).

Is there any other infrastructure that would need to be updated around
CGEN?  I am happy to help with (or do) script rewrites if that is
required.

Next Steps
==========

What I think needs to happen next:

 + Interested people review the conversion and give feedback.
 + I update based on feedback and repeat until we're all happy.
 + I and/or others update any support scripts that are identified.
 + Create a git repository on sourceware.org and import conversion.
 + Switch cgen part of old CVS repository to read only mode.

The feedback and update depends on people reviewing and giving feedback.

I don't have permissions to create a git repository on sourceware, or
change the admin settings on CVS, nor am I sure who to approach.  When
we get that far any advice would be great.

Finally, is there anything else I can or should do to help make this happen?

Thanks,
Andrew

^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2019-04-22  9:43 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-01-31 19:50 Converting CGEN from CVS to git Andrew Burgess
2019-02-02  9:35 ` Jose E. Marchesi
2019-02-03 16:30 ` Frank Ch. Eigler
2019-02-04  8:25   ` Jose E. Marchesi
2019-02-04 13:51     ` Frank Ch. Eigler
2019-02-04 16:33   ` Andrew Burgess
2019-03-03 22:38     ` Frank Ch. Eigler
2019-03-06 13:28       ` Andrew Burgess
2019-03-27 14:32         ` Andrew Burgess
2019-03-27 20:09           ` Frank Ch. Eigler
2019-04-21 16:23             ` Andrew Burgess
2019-04-21 16:42               ` Frank Ch. Eigler
2019-04-21 19:39                 ` Andrew Burgess
2019-04-21 21:32             ` Andrew Burgess
2019-04-22  9:43               ` Jose E. Marchesi

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).