[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Moving to git
Re: Moving to git
Sun, 4 Jan 2009 00:05:07 +0100
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
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
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?
Description: Digital signature
- Re: Moving to git,
Thomas Schwinge <=