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