C. Michael Pilato <cmpilato_at_collab.net>:
> The "replace"
> action found in the dumpfile is just a compacting of some delete operation
> and a subsequent add or copy into a single verb, and that only because it
> helps sequential processors of the dump stream avoid possibly notifying
> about multiple actions on the same path
Thank you. That is beautifully clear and I will use some variant of
it it in the draft I am working up.
Which brings up a question: should a delete on a non-empty directory succeed
or fail?
If it should succeed, then R truly is D + A. If it should fail, then R
lacks a precondition that D + A has.
> (My prior response was the result of my misreading your phrase "delete plus
> add of the new text" as meaning "removing all the contents of the file, and
> then adding all new contents of the same file". I see now that you were
> talking about "container" operations, not content ones. Sorry about that.)
No problem. Easy mistake to make.
> >> [1] Most of the time. A replacement can have a copyfrom source, in which
> >> case its not strictly a new line of history for that object.
> >
> > I think I get this part. When you replace with a copy source, you're
> > destroying the container that existed at this path, abd replacing it with
> > a new container that has history extending back through the copy source.
> > Is that correct?
>
> Yup!
IMO, part of the reason this stuff is confusing is that your
terminology is inadequate; see previous note to Daniel Shahaf. I get
what you mean by "container" but I think that label confuses more than
it enlightens. In the draft I'm using the term "flow" for a sequence
of actions on a path.
> I was trying to think through the generalities here, too. I believe they
> boil down to this:
>
> "delete" stands alone. It never has text. Never has properties.
> Never has copyfrom.
>
> "add" and "replace" can have text if the added object is a file. The
> text is the contents of the added object as it appears in the committed
> revision. "add" and "replace" of directories can not have text.
>
> "add and replace" can have properties -- the set of properties present
> on the added file/directory in the committed revision.
>
> "add and replace" can have copyfrom information, indicating that the
> "added" object does not truly represent the creation of a new line of
> history, but is instead a continuation of a pre-existing line of
> history. This is still an addition of sorts in that the object is newly
> added to the set of its parent directory's list of children.
>
> But I haven't double-thunk that for complete accuracy.
I'm actually pretty sure this is all correct - but it leaves open the question
of whether "change" can have copyfrom, and what that means in the case
of directories.
I checked, and "change" is what's used for a normal file content
modification - see for example the change to bar/foo.c in sussman's
example in the notes file.
There are a couple of different possibilities here. One is that change with
a copyfrom is illegal. In that case, every directory change is required
to be a property change, since directory nodes can't have text. This is
what my draft currently says.
Another possibility is that copyfrom does its history-attachment thing and
the note is afterwards part of two flows. That would be rather like a
baby version of a DVCS merge.
You wrote:
> This is still an addition of sorts in that the object is newly
> added to the set of its parent directory's list of children.
For what operations is this list of children significant, and how? Which
circles back to my first question about D on a directory.
--
Eric S. Raymond
Received on 2011-12-14 13:12:17 CET