Goals

[Tom Lord]

    > From: David Waite <mass at akuma.org>

    > >[me:]
    > >I don't see a need to more explicitly surface the textual DAG in the
    > >changeset format -- indeed it seems undesirable to require
    > >changeset-generation tools to _have_ to do that computation when it
    > >can just as easily be done by changeset-receiving tools, only some of
    > >which need the DAG anyway.
    > >
    > Is the problem that I said that the graph should be assumed to be a 
    > straight line, when really nothing should be assumed? I'm sure we both 
    > agree that a changeset generation tool should not have to generate a 
    > DAG, just that it may be already known and important to serialize into 
    > the changeset.

There's no problem.   

A "composite" or "recursive" changeset is likely to imply a total
order of its components.   For example, if serialized as a text stream
-- the order of components in that stream is a total order.

Textually, there is a partial order among components.   Overlapping
hunks of text patches in two components must be applied in some
definate order --- but which order?  A or B, or B or A?

All I meant is that a natural view is that if the textual partial
order requires A,B, then in the total order A<B.   So, considering
text (we'd have to make other decisions for other diff types) the hunk
line numbers plus the total order within the composite changeset make
the textual partial order easy to compute.


    > Actually, that would still be order-dependant. Lets say one (very 
    > inefficient) algorithm for applying the changeset to file set ORIG in 
    > directory ./ORIG is to create a directory ./NEW and to recreate the 
    > files within set ORIG in that dir. The lack of a file content change 
    > means the file contents were not altered; the lack of a tree change 
    > indicates the file did not move. In this sort of setup, it is easy to 
    > see that a pair of (filename A -> B', filename B -> A') changes can be 
    > represented, and that no particular order is needed to evaluate these 
    > changes. Assuming the patch replacement tool works in-place, it will 
    > have to know that there will be a filename conflict and use an 
    > intermediate temporary file during the move.

Then we're (approximately) talking about isomorphic solutions in
different terms.   You seem to want to introduce some notion of
"primitive changeset" that I think is needlessly primitive.

    > (Using 'set of changes' to keep from getting confused about the 
    > possibility of grouped changesets, ) I'm more concerned about having a 
    > single set of changes which alters the same file multiple times, or 
    > changes the name of file A to B and then C. The primitive changes should 
    > be grouped so that there isn't an intradependancy.
    > 
    > Now, one case that could conflict is moving A to B, and creating a new A 
    > in the same set of changes. One solution for this is to have a 'create' 
    > primitive represent both a tree change and content change; both a 
    > 'patch' representing the full new file without name, and a move to its 
    > real name. Same deal with a deletion.

The arch changeset format handles such problems quite well, using a
solution quite unlike what you describe.   

As I mentioned a little while ago, I'm getting sleepy -- if you're
feeling like digging in to the issue, you could do worse than grab the
arch source code and start reading src/arch/patch-sets.

-t