[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu-arch-users] the state of the union
From: |
Tom Lord |
Subject: |
Re: [Gnu-arch-users] the state of the union |
Date: |
Tue, 17 Aug 2004 19:19:46 -0700 (PDT) |
> From: Andrew Suffield <address@hidden>
> > In the past, efforts to unify the changeset mechanisms of the
> > various projects failed. The primary sticking point seems to have
> > been disagreement about the necessity and desirability of inventory
> > tags.
> Ironically, one of the "major" points on my semi-formal list of things
> I'd like to see in the next changeset format, is to orient changesets
> around logical file identity ("inventory tags") rather than
> filenames.
I'm unclear what you mean by "orient" here.
Changesets have a pretty clear abstract structure. The individual
file diffs happen to be stored in the tar bundles by filename, but the
file id -> patch mapping is utterly trivial to compute from that plus
the index files. How in the world could changesets be more
"oriented around logical file identity?"
> The metaphor just makes much more sense; it's the only
> intelligent way to describe changesets as functions,
I don't know about only but I agree that changesets (under the dopatch
point of view) are functions (mapping input trees to output trees
under the rules of possibly-inexact patching).
I expect arch to evolve in this area, btw. Domain-specific
replacements for mkpatch/dopatch (not necessarily per-file --- even
per-tree) open up a wealth of possibilities.
> and would eliminate most of the strange edge cases we see with
> inexact patching. More on that when we get to the point where we
> can start designing the next format (at this rate it'll probably
> be tla 2.0).
> I believe that this approach will give an extremely simple description
> of how to apply a changeset, which behaves in the expected manner in
> all cases (generating a changeset won't appreciably change).
I'd like to hear more specifics about what "this approach" is. So far
it sounds like a noop permutation of what's already there.
>
> > Indeed, cherrypicking has proven very useful in Arch. And=20
> > the reason cherrypicking works in arch is because of our changeset
> > format. And the reason our changeset format works is because of
> > inventory tags.
> Don't underestimate that point. It's also the primary difference
> between arch and svn - and in fact, monotone is pretty much
> functionally equivalent to svn in every significant respect.
I think that monotone's weirdness around manifests is pretty
un-svn-like. I strongly second your larger point that, of all
things, inventory ids are really the killer meme that makes arch
possible. Everything else is layered on that.
> Here's how I like to phrase it to make the point blindingly obvious:
> Everybody knows that changesets and tree-versions are interchangeably
> convertable. Given one, you can generate the other.
> This is only true in the presence of complete history.
! Yes. As you probably know, you are compressing the whole failed
"common changeset" dialog to the obfuscated wedge issue that broke it
up. The only self-consistent position against inventory ids is one
that denies the utility of distributed revision control (because in
centralized control, complete history is always available).
> The fundamental conversions are:
> A complete history of tree-versions converts to a complete sequence of
> changesets.
> A tree snapshot and a changeset converts to a pair of tree-versions.
> When you have a history *fragment*, you can still generate
> tree-versions from changesets. You can't do a single damn thing with a
> history fragment expressed as tree-versions, except to fetch one of
> them.
> The ability to fragment history in this manner is what we mean when we
> talk about "distributed development". And no, monotone doesn't do
> it. It just hauls complete history around to all the clients.
Nicely said. Definately different then how I would have expressed
the same facts and so hopefully useful. I'll have to remember that
way of putting it.
Along these same lines: a changeset corresponds to a commit and that
is an (approximate) expression of a logical transformation rather than
just a literal set of text diffs. You describe changesets as
"functions": those functions are, in some sense, what arch-using
programmers are in the business of writing.
> In the simplest possible terms:
> We can do something intelligent with the contents of a *single*
> revision (that is, one changeset), including merge it. The only thing
> you can do with a single revision in the other systems is to fetch it.
> > * CA Response: Do Not Be Afraid of the XL
> > If Jblack's attitude towards XL is at all typical I've done a
> > hopelessly bad job of explaining my intentions.
> Personally I'm reserving judgement. I can guess at what you're
> thinking but don't see any point in doing so.
> Furth itself I'm already happy about because I've figured out how to
> wedge any arbitrary language into it - it's like the exec() barrier,
> only better. It's overcomplicated for this problem but I don't
> care. So it's not possible for you to screw that part up.
That's a good sign. (I.e., design aspects that achieve that level of
plausible inevitability and obviousness that nobody owns them. They
become a universal technique rather than an arbitrary aesthetic
choice.)
I agree about the characterization of the furth inner interpreter as
an exec()-like barrier.
Add to that the combined ideas of a generic collection of lisp-like
Values (i.e., uncomplicated sum and product types over a few basic
domains, so that data can be universally exchanged without excessive
or exclusionary type-system hair) and a register machine abstraction
as the basis of the right approach to FFI design and you're there --
xl is the one with second-least-amount of hair for Values, Furth is
next, and Pika is fully general.
If you know what I mean.
-t
- [Gnu-arch-users] the state of the union, Tom Lord, 2004/08/17
- Re: [Gnu-arch-users] the state of the union, Andrew Suffield, 2004/08/17
- Re: [Gnu-arch-users] the state of the union,
Tom Lord <=
- Re: [Gnu-arch-users] the state of the union, Andrew Suffield, 2004/08/17
- Re: [Gnu-arch-users] the state of the union, Tom Lord, 2004/08/17
- Re: [Gnu-arch-users] the state of the union, Andrew Suffield, 2004/08/18
- Re: [Gnu-arch-users] the state of the union, Tom Lord, 2004/08/18
- Re: [Gnu-arch-users] the state of the union, Andrew Suffield, 2004/08/18
[Gnu-arch-users] Re: the state of the union, Miles Bader, 2004/08/17