Re: Kernel SCM saga..
From: Tupshin Harper
Date: Fri Apr 08 2005 - 18:48:25 EST
Roman Zippel wrote:
Preserving the complete merge history does indeed make repeated merges
simpler, but it builds up complex meta data, which has to be managed
forever. I doubt that this is really an advantage in the long term. I
expect that we were better off serializing changesets in the main
repository. For example bk does something like this:Both darcs and arch (and arch's siblings) have ways of maintaining the
complete history but speeding up operations.
A1 -> A2 -> A3 -> BM
\-> B1 -> B2 --^
and instead of creating the merge changeset, one could merge them like
A1 -> A2 -> A3 -> B1 -> B2
This results in a simpler repository, which is more scalable and which
is easier for users to work with (e.g. binary bug search).
The disadvantage would be it will cause more minor conflicts, when changes
are pulled back into the original tree, but which should be easily
resolvable most of the time.
Arch use's revision libraries:
though i'm not all that up on arch so I'll just leave it at that.
Darcs uses "darcs optimize --checkpoint"
which "allows for users to retrieve a working repository with limited
history with a savings of disk space and bandwidth." In darcs case, you
can pull a partial repository by doing "darcs get --partial", in which
case you only grab the state at the point that the repository was
optimized and subsequent patches, and all operations only need to work
against the set of patches since that optimize.
Note, that I'm not promoting darcs for kernel usage because of speed (or
the lack thereof) but I am curious why Linus would consider monotone
given its speed issues but not consider darcs.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/