[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Moving to git
From: |
olafBuddenhagen |
Subject: |
Re: Moving to git |
Date: |
Fri, 9 Jan 2009 09:38:20 +0100 |
User-agent: |
Mutt/1.5.18 (2008-05-17) |
Hi,
On Sun, Jan 04, 2009 at 12:05:07AM +0100, Thomas Schwinge wrote:
> 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.
So? No need to drop dead branches -- they can still be interesting for
reference.
It's not like dropping them helps with anything...
> 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.
Don't do that. The whole point of a revision control system is to
preserve history... A "blob" commit is unmanageable.
If you think the history of the branch(es) is too messy, you can of
course start a new branch, say xen-cleanup. This new branch should still
contain a series of individual changes though, even if they don't
reflect actual development history.
(The latter is the standard practice in Linux development, BTW.)
> 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.
Sounds like a lot of additional work and potential confusion, for very
little benefit...
> Split Hurd modules into separate repositories.
I stand by what I said on this topic before: *If* we decide to make such
a change, it should be done independently of the Git migration.
It would hold up the migration; it would mix a purely technial action
with fundamental decisions.
> 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.
Is there a reason to keep them seperate?...
> libihash and libpthread are shared between Hurd and Viengoos.
I agree that these should be split out, but probably also not during the
git migration...
> 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.
Indeed, it's not possible to properly disentangle the modules
retrospectively. So we *have* to keep the original history, even if we
really want the split to happen ultimately.
This is also a reason why the split should happen only after the git
conversion.
> * 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.
This is the main reason why I'm not convinced the split is a good idea
at all. We would need to start some proper versioning, which is quite a
pain. And what would the benefit be? It's not like we ever release these
modules seperately... (At least not in the forseeable future.)
-antrik-