Re: Moving to git

[Thomas Schwinge]

Hello!

On Mon, Dec 08, 2008 at 09:36:25AM +0100, I wrote:
> On Thu, Nov 20, 2008 at 11:12:21AM +0100, Neal H. Walfield wrote:
> > I'd like to propose that we move from CVS to git.
> 
> I intend to do the repository conversion until the end of this year.

Well, that didn't work out, but here is my plan, some decisions together
with some reasoning.

Only convert GNU Mach's gnumach-1-branch, GNU MIG's HEAD, GNU Hurd's
HEAD.

    With the exception of the GNU Mach Xen branch and the Hurd GSoC
    branches, these are the only branches that see active development.

    For the GNU Mach Xen branch, I'd like Samuel to tell when that one is
    ready for being merged into the main GNU Mach 1 branch and then I
    intend to do that merge as one big aggregated ``blob'' (i.e., without
    preserving the individual development, testing, debugging,
    etc. commits.  The same holds for the GSoC branches.  We can, of
    course, also easily publish these again as separate git branches,
    based on the new git master branch (former CVS HEAD).  Just tell me
    what you'd like.


Conversion will be done with CVS / RCS keyword expansion switched off.


Exclude all automatically regeneratable and Debian package maintenance
files from the conversion.

    These files are no longer present in current checkouts (general
    change of policy), but they do occupy a non-insignificant amount of
    space in revision history, and are not interesting with respect to
    preserving their history.  (They might be interesting if someone
    indeed wants to build an old version, but this is a corner-case that
    can be worked around easily.)

    The files will simply be excluded from the conversion.  ChangeLog
    entries referncing them will not be changed in flight (too
    time-consuming for no net benefit).  Instead a follow-up clean-up
    patch will weed out all ChangeLog entries referencing them.


Split Hurd modules into separate repositories.

    Rationale: split as far as it's still making sense.  There is no
    reason to have an interger hashing library, a pthread implementation,
    an ext2 file system interpreter, libc amendments, Hurd interfaces
    definition files, a library for providing an uniform interface to
    Mach ports, etc. in the same repository.

    libihash and libpthread are shared between Hurd and Viengoos.
    libihash is actually not at all dependent on (any sort of) the Hurd.


    Git submodules can easily be used to construct the same checkout tree
    again (for easy building).  This repository (the one containing the
    submodules information) will also be the one containing the build
    system, release stuff (if that is at all still considered for
    inclusion), documentation (for now, until it is split up).


    Probobably the point of splitting will simply be the separate
    top-level subdirectories.  Perhaps things like hostmux and usermux
    and other simple translators will be kept aggregated.  Likewise
    libcons and console-client (and console?), or libftpconn and ftpfs
    (but the former is also used in utils/ftp*.)


    Checking the state after having done a whole-repository conversion
    yields several change sets that span files in more than one of the
    new modules.

    If ChangeLog messages referencing several modules will be changed in
    flight is not yet decided, but probably not, as that applies only to
    a minor parts of the affected changes / files:

      * The vast majority of them are from the initial imports
        (``Formerly Makefile.~4~'' as commit message for both
        fstests/Makefile and libiohelp/Makefile, but the changes being
        totaly unrelated), or aggregations of Roland's and Miles' ``.''
        and Thomas' ``*** empty log message ***'' commit messages --
        aggregated due to the same text in the commit message, same
        author, and within the same ``fuzzy'' time period.  Also in this
        category are all the ``Initial import'', ``Initial revision'',
        ``entered into RCS'' commits.

      * A few others are for interface changes and follow-up adjustment
        in the interface-using modules (libihash rewrite, for example).
        (Likewise for build system enhancements or changes, as adding
        uselocale for libthreads, or adding libncursesw for
        utils/console-ncurses.c, for example.)  Or adding a driver for
        streamio devices and adding a stanza for these in the MAKEDEV
        script at the same time.  Also, there are a few (notable!)
        interface changes, where the aggregated documentation in `doc/'
        has been updated together with committing the interface change.
        Likewise for changes where the top-level TODO or tasks file has
        been updated together with committing a change.  All these
        changes will be broken up.  Future interface changes will be done
        using some sort of versioning.

      * The same change (functionally) was done in several modules (in
        ext2fs and fatfs, for example, or in hostmux and usermux).

      * Wrong ChangeLog file used when committing a change.

      * Committing unrelated changes (to several modules) in one go.
        Also, removing several modules' dead files at the same time.

      * Files moved from one module to another.

        Perhaps move these to current destination place right from the
        beginning, before doing the conversion?


What do you think so far?


Regards,
 Thomas

signature.asc
Description: Digital signature