[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Sun, 04 Jan 2009 10:37:18 +0100
Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)
Thomas Schwinge <email@example.com> writes:
> 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
> 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?
Description: PGP signature