On Tue 11 Mar 03 19:46, Martin J. Bligh wrote:
> > I've taken a lot of stuff from that wish list, combined it with what I
> > gathered from Larry's earlier post, and from Petr Baudis' recent post,
> > and elsewhere, and organized it into something that might be interesting.
> > If anyone would like to host this document on the web, please let me
> > know.
>
> Not sure if this was captured before (I don't see it explicitly in what
> you sent), but one thing that I don't think current tools do well is to
> keep changes seperated out. We need to be able to put a stack of 200
> patches on top of 2.5.10, then be able to break those out again easily
> come 2.5.60, once we've merged forward. Treating things as one big blob
> will work great for Linus, but badly for others.
Coincidently, I was having a little think about that exact thing earlier
today. Suppose we call the process of turning an exact delta into a
delta-with-context, "softening". So you select a set of deltas somehow
(e.g., all deltas in wild-card set of files) then soften them by adding
context, or in the deluxe version, convert to lists of tokens with whitespace
markup. The result is a first-class object in the database, called a, hmm,
soft changeset? (Surely there is a better name.)
A soft changeset can be carried forward in the database automatically as long
as there are no conflicts (like patch with fuzz) and where there are
conflicts, the soft changeset itself can be versioned. To implement soft
changeset versioning the lazy way, just merge the changeset with some version
and generate a new soft changeset against some other version. A name for the
versioned soft changeset can be generated automatically, e.g.:
changset.name-from.version-to.version.
You can wave your wand, and the soft changeset will turn into a universal
diff or a BK changeset. But it's obviously a lot cleaner, extensible,
flexible and easier to process automatically than a text diff. It's an
internal format, so it can be improved from time to time with little or no
breakage.
Did that make sense?
> At the moment, I slap the patches back on top of every new version
> seperately, which works well, but is a PITA.
Tell me about it.
> I hear this is something
> of a pain to do with Bitkeeper (don't know, I've never tried it).
> People muttered things about keeping 200 different views, which is
> fine for hardlinked diff & patch (takes < 1s to clone normally), but
> I'm not sure how long a merge would take in Bitkeeper this way? Perhaps
> people who've done this in other SCM's could comment?
I've never seriously used any commercial SCM, so nobody can accuse me of
stealing their ideas. On the other hand, it means I may have to take a few
shots way wide of the target before hitting any bullseyes.
Regards,
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Mar 15 2003 - 22:00:26 EST