Thomas Schwinge <tschwi...@gnu.org> writes:
> 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
pgpLKGGF9T3SP.pgp
Description: PGP signature
