On Wed 12 Mar 03 21:37, Horst von Brand wrote:
> Daniel Phillips <phillips@arcor.de> said:
> > This is why changesets need to be first-class objects in the repository,
>
> Right.
>
> > that can be versioned,
>
> Versioned how? Have different versions of a changeset? Don't see the point.
So that fix.foobar-2.5.64 that you got from davem applies to 2.5.64 that you
got from Linus, and a later version of it, e.g., with some macro respelled by
you (in line with Linus's recent changes) applies correctly to 2.5.69.
> ...The changeset should be seen as a (conceptually atomic)
> change to the _local_ repository.
No argument there, and no inconsistency. Well, except that it's entirely ok
to "soften" a changeset by adding context and send it off to somebody else.
That somebody else may need to massage it to get it to apply, and so they end
up with the exact changeset you sent them, which conflicts, and their own
version of it, which works. Then, when somebody asks them to forward the
same changeset , they've got two chances to send one that works on the first
try. And so on forth.
> The "conceptually atomic" part is from
> Linus' style of "break up your megapatch into self-contained pieces, do one
> step at a time".
Really essential.
> The changeset must make local sense if you want to be able
> to undo, see what it changes, handle dependencies, ... Locally, what was
> changed remotely (generating the changeset in the first place) is useless
> (as the context isn't here).
Yes, but I fail to see why that means you can't send the thing on to someone
else to accomplish something useful. This has always worked well with
patches, why did it stop working with changesets?
> > and recombined.
>
> Recombined how? Take changesets A and B, create C from half of each? Better
> keep A, B, and create another one that gets rid of the junk.
Yes of course. Why would you throw any changeset away? It's all good data.
C would be a recombination of A and B, and all of them end up in the
repository, though not necessarily all applied.
In order to recombine efficiently, you have to be able to explode A and B
into their component parts (chunks make a convenient starting point) then
reassemble them, hopefully with the help of regex matches and so on. You
also want to be able to do the equivalent of editing a patch, but in a way
that isn't so error-prone. A nice way to do that is to apply the patch, edit
the result, then regenerate the patch. The tedious bookkeeping aspect of
this can be automated nicely.
> Or do a C from
> scratch (perhaps by applying A and B as patches, fixing up the mess, and
> declaring the resulting change a changeset).
Yes.
> It does make sense to group changesets, but not this way AFAICS.
>
> > I'd be able to pull
> > slightly differing changesets from a variety of sources, *merge
> > the changesets* and carry the result forward in my repository. This
> > way, no changeset needs to lose its identity until I explicity want it
> > to.
>
> This is doing merging among changesets, not merging changesets into the
> repository.
No, I meant merging the changesets into the repository. Then the system
regenerates the changeset, and understands it to be a descendant version of
the original changeset. The result is a "merged" changeset, i.e., one that
applies correctly, whereas the original didn't.
> I'd prefer the later (as it reduces this special-purpose
> operation to others that have to be there anyway).
I suppose that we're violently agreeing, and just haggling over terminology.
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:33 EST