You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Philip Martin <ph...@wandisco.com> on 2011/12/13 10:52:27 UTC
Re: Problems with the documentation of Subversion dump format
esr@thyrsus.com (Eric S. Raymond) writes:
> # The "replace" action [?is only issued with directory copies, and?]
> # signifies that the existing contents of the directory should be
> # removed before the copy.
Replace applies to files as well.
> # Interpreting copyfrom_path for file copies is straightforward; the
> # target pathname gets the contents of the source pathname.
> #
> # Directory copies (the primitive beneath branching and tagging) are
> # tricky. For each source path under the source directory, a new path
> # is generated by removing the head segment of the pathname that is
> # the source directory. That new path under the target directory gets
> # the content of the source path.
Not sure what this means. This copies A/B/C to X/Y/Z:
Node-path: X/Y/Z
Node-kind: dir
Node-action: add
Node-copyfrom-rev: 10
Node-copyfrom-path: A/B/C
> # A single revision may include multiple copyfrom nodes, even multiple
> # copyfroms to the same directory, even mixed directory and file copies
> # to the same directory; [?Subversion client tools never generate such
> # mixed copies, but?] I have seen the results of cvs2svn doing it.
Not sure what "mixed directory and file copies to the same directory"
means or why Subversion clients would be restricted. Given directories
D1 and D2 and a file F it's trivial to copy D1 to D2/Dnew and F to
D2/Fnew.
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Re: Problems with the documentation of Subversion dump format
Posted by Stephen Butler <sb...@elego.de>.
On Dec 13, 2011, at 16:37 , Daniel Shahaf wrote:
> Eric S. Raymond wrote on Tue, Dec 13, 2011 at 09:44:59 -0500:
>> Yes, but in a single copy command? My experience is that every one copy
>> operation done from the CLI triggers a commit.
>
> Not every single 'svn cp' invocation triggers a commit.
i.e., you could run 'svn cp' several times in a working copy, and then
commit once with 'svn ci'.
Steve
--
Stephen Butler | Senior Consultant
elego Software Solutions GmbH
Gustav-Meyer-Allee 25 | 13355 Berlin | Germany
tel: +49 30 2345 8696 | mobile: +49 163 25 45 015
fax: +49 30 2345 8695 | http://www.elegosoft.com
Geschäftsführer: Olaf Wagner | Sitz der Gesellschaft: Berlin
Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
Re: Problems with the documentation of Subversion dump format
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Eric S. Raymond wrote on Tue, Dec 13, 2011 at 13:30:10 -0500:
> Daniel Shahaf <d....@daniel.shahaf.name>:
> > Eric S. Raymond wrote on Tue, Dec 13, 2011 at 09:44:59 -0500:
> > > Yes, but in a single copy command? My experience is that every one copy
> > > operation done from the CLI triggers a commit.
> >
> > Not every single 'svn cp' invocation triggers a commit.
>
> I've never been able to stop it. What's the actual trigger condition?
>
'svn cp' commits iff the last target argument is a URL.
> > And, by the way, dumpfiles need to represent things that cannot be done
> > with plain 'svn'.
>
> Yeah, I figured that out already from looking at some of the weird stuff
> cvs2svn committed in the back history of NUT-UPS. This is a point that
> needs to be clearer in the documentation.
The documentation should say that dumpfiles must be able to represent
everything the public svn_fs.h API allows. (Or, at least, that subset
of that API that svn_repos.h also exposes... if they differ?)
Re: Problems with the documentation of Subversion dump format
Posted by "Eric S. Raymond" <es...@thyrsus.com>.
Daniel Shahaf <d....@daniel.shahaf.name>:
> Eric S. Raymond wrote on Tue, Dec 13, 2011 at 09:44:59 -0500:
> > Yes, but in a single copy command? My experience is that every one copy
> > operation done from the CLI triggers a commit.
>
> Not every single 'svn cp' invocation triggers a commit.
I've never been able to stop it. What's the actual trigger condition?
> And, by the way, dumpfiles need to represent things that cannot be done
> with plain 'svn'.
Yeah, I figured that out already from looking at some of the weird stuff
cvs2svn committed in the back history of NUT-UPS. This is a point that
needs to be clearer in the documentation.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
Re: Problems with the documentation of Subversion dump format
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Eric S. Raymond wrote on Tue, Dec 13, 2011 at 09:44:59 -0500:
> Yes, but in a single copy command? My experience is that every one copy
> operation done from the CLI triggers a commit.
Not every single 'svn cp' invocation triggers a commit.
And, by the way, dumpfiles need to represent things that cannot be done
with plain 'svn'.
Re: Problems with the documentation of Subversion dump format
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
On Wed, Dec 14, 2011, at 06:36, Eric S. Raymond wrote:
> Daniel Shahaf <d....@daniel.shahaf.name>:
> > Replace requires a node to already exist at the target path.
> >
> > Add requires a node to not already exist.
>
> OK, when you say "require", what do you mean? Just that if these conditions
> fail the node should not be modified?
>
If these condition fail I believe 'svnadmin load' aborts without
committing the revision they appear in (but with prior revisions having
already abeen commited)
> > (container == node)
>
> I see what you mean, but I think this is misleading terminology. The thing
> you are calling a "container" is a history containing a sequence of actions
> each one of which is *described* by a node.
>
Sorry, no. I said "node"; what you call a "node" is termed "node-
revision" in the FS.
See subversion/libsvn_fs_base/notes/
> IMO the term "container" isn't a win either; it doesn't convey a
> strong enough sense of continuity over time.
>
> In the draft I'm working on, I've used the term "flow", and defined a
> flow as a sequence of actions on a path.
Re: Problems with the documentation of Subversion dump format
Posted by "Eric S. Raymond" <es...@thyrsus.com>.
Daniel Shahaf <d....@daniel.shahaf.name>:
> Replace requires a node to already exist at the target path.
>
> Add requires a node to not already exist.
OK, when you say "require", what do you mean? Just that if these conditions
fail the node should not be modified?
> (container == node)
I see what you mean, but I think this is misleading terminology. The thing
you are calling a "container" is a history containing a sequence of actions
each one of which is *described* by a node.
IMO the term "container" isn't a win either; it doesn't convey a
strong enough sense of continuity over time.
In the draft I'm working on, I've used the term "flow", and defined a
flow as a sequence of actions on a path.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
Re: Problems with the documentation of Subversion dump format
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Eric S. Raymond wrote on Tue, Dec 13, 2011 at 13:25:13 -0500:
> C. Michael Pilato <cm...@collab.net>:
> > > Does a file replace differ in any way from a delete plus add of the new text?
> >
> > In Subversion, yes. A replacement is, like an add or a delete, an operation
> > at the node level, not an operation on the contents of that node. A replace
> > is an addition of a new object[1] -- with its own new line of version
> > control history -- that is coincidental with the removal of some previously
> > existing object that occupied the same path.
>
> I still don't understand how this differs from a delete followed by an add.
> Explain it to me like I'm reallllyyy stuuupid, please, so I can document it
> and you never have to explain it again.
>
> When I add a file at a given path, it creates new object with a
> history that is tracked. When I delete that path, I destroy the
> container as well as the content. If I subsequently create a new
> file at the same path, it's a new object with its own history.
>
> How is a replace different?
>
Presumably:
Replace requires a node to already exist at the target path.
Add requires a node to not already exist.
For comparison, the svn_delta_editor_t documentation talks about the
relative order delete_entry()/add_file()/add_dir() of the same path in
the same editor drive.
> > [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?
>
Yes
(container == node)
Re: Problems with the documentation of Subversion dump format
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 12/14/2011 09:47 AM, Eric S. Raymond wrote:
> Heh. Just to add to the confusion, Daniel says that what I'm calling a
> "flow" is elswehere called a "node" and that what I'm calling a "node"
> is elsewhere called a "node-revision".
>
> I'm not sure how I want to deal with this in the 0.3 draft. The
> problem with what he's telling me is the correct terminology leaves
> the term "node" pretty overloaded. Best thing may be to change "node"
> in the document to "node-revision" and leave in "flow" with a note
> indicating that the source code sometimes calls this a "node".
Yup.
A "node-revision" is, in svn-fs-speak, a single node in the giant DAG which
describes the whole of the version history in the repository. It represents
the state of a file or directory as it existed a given point in version time.
A "node", though, is not a node in that DAG at all, but the term used to
describe a whole set of those nodes (aka "node-revisions") connected in the
DAG by their ancestor IDs. A "node" describes the line(s) of history of a
single versioned object (file, or directory, including all states thereof
including those resulting from copy operations).
So, yeah, one node is a "node-revision", and a collection of
"node-revisions" is a "node". We probably could have done a bit better when
naming this stuff...
Fortunately, there is no confusion about one thing: the term "flow" has not
a single meaning at all in Subversion-speak. :-)
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Problems with the documentation of Subversion dump format
Posted by "Eric S. Raymond" <es...@thyrsus.com>.
C. Michael Pilato <cm...@collab.net>:
> On 12/14/2011 07:11 AM, Eric S. Raymond wrote:
> > Which brings up a question: should a delete on a non-empty directory succeed
> > or fail?
>
> Succeed.
Thank you, that will go into the 0.3 draft.
> > 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 agree about the terminology. I was trying (and failing, it seems) to
> adapt to your own terminology. What a tangled web we weave...
Heh. Just to add to the confusion, Daniel says that what I'm calling a
"flow" is elswehere called a "node" and that what I'm calling a "node"
is elsewhere called a "node-revision".
I'm not sure how I want to deal with this in the 0.3 draft. The
problem with what he's telling me is the correct terminology leaves
the term "node" pretty overloaded. Best thing may be to change "node"
in the document to "node-revision" and leave in "flow" with a note
indicating that the source code sometimes calls this a "node".
> The copyfrom attribute was designed to be valid only on "add" and "replace",
> not "change" (or "delete"). And yes, directory changes may only contain
> properties after the header block -- no text.
Good, that certainly simplifies life. Please have a look at the 0.2 draft
and see what if anything needs fixing.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
Re: Problems with the documentation of Subversion dump format
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 12/14/2011 07:11 AM, Eric S. Raymond wrote:
> Which brings up a question: should a delete on a non-empty directory succeed
> or fail?
Succeed.
> 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 agree about the terminology. I was trying (and failing, it seems) to
adapt to your own terminology. What a tangled web we weave...
> 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.
The copyfrom attribute was designed to be valid only on "add" and "replace",
not "change" (or "delete"). And yes, directory changes may only contain
properties after the header block -- no text.
>> 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.
Let's not go here. I was trying to justify the use of the term "add" in the
context of a copied item (which, in one sense, isn't a new thing at all).
My attempt can only possibly create confusion, so I advise that we all just
forget I said it. :-)
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Problems with the documentation of Subversion dump format
Posted by "Eric S. Raymond" <es...@thyrsus.com>.
C. Michael Pilato <cm...@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.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
Re: Problems with the documentation of Subversion dump format
Posted by Johan Corveleyn <jc...@gmail.com>.
On Tue, Dec 13, 2011 at 11:52 PM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> Johan Corveleyn wrote on Tue, Dec 13, 2011 at 22:04:33 +0100:
[...]
>> And even:
>>
>> $ svn mv some/file.txt some/otherfile.txt
>> $ svn mv some/otherfile.txt some/file.txt
>> $ svn ci -m "Replace some/file.txt with a copy of itself."
>>
>> (pre-1.7 this would be a replace without copyfrom, breaking the line
>> of history [1], but that is fixed as of 1.7)
>>
>
> But the fix is client-side, right? One can still do things like that by
> driving an RA commit editor directly.
Oh yes, that was purely a client-side problem, which was fixed by the
better capabilities of WC-NG. In theory the client could just as well
translate the above series of commands into a simple modification,
instead of a replace with history (copied from itself). But that
doesn't happen in practice :-). Anyway, I guess this is getting off
topic for this thread ...
--
Johan
>> [1] http://subversion.tigris.org/issues/show_bug.cgi?id=3429 - "svn mv
>> A B; svn mv B A" generates replace without history
Re: Problems with the documentation of Subversion dump format
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Johan Corveleyn wrote on Tue, Dec 13, 2011 at 22:04:33 +0100:
> On Tue, Dec 13, 2011 at 8:16 PM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> > C. Michael Pilato wrote on Tue, Dec 13, 2011 at 14:01:45 -0500:
> >> On 12/13/2011 01:25 PM, Eric S. Raymond wrote:
> >> > C. Michael Pilato <cm...@collab.net>:
> >> >>> Does a file replace differ in any way from a delete plus add of the new text?
> >> >>
> >> >> In Subversion, yes. A replacement is, like an add or a delete, an operation
> >> >> at the node level, not an operation on the contents of that node. A replace
> >> >> is an addition of a new object[1] -- with its own new line of version
> >> >> control history -- that is coincidental with the removal of some previously
> >> >> existing object that occupied the same path.
> >> >
> >> > I still don't understand how this differs from a delete followed by an add.
> >> > Explain it to me like I'm reallllyyy stuuupid, please, so I can document it
> >> > and you never have to explain it again.
> >> >
> >> > When I add a file at a given path, it creates new object with a
> >> > history that is tracked. When I delete that path, I destroy the
> >> > container as well as the content. If I subsequently create a new
> >> > file at the same path, it's a new object with its own history.
> >> >
> >> > How is a replace different?
> >>
> >> Assume your "delete" and subsequent "add" happens in the same commit, it's
> >> not different at all. In fact, the Subversion filesystem API doesn't even
> >> recognize a "replace" operation. There's "delete (file or dir)", there's
> >> "make file" and "make dir", and there's "copy (file or dir)". 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. We favor the likes of:
> >>
> >> R /some/file.txt
> >>
> >> over:
> >>
> >> D /some/file.txt
> >> A /some/file.txt
> >>
> >> in output.
> >>
> >> (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.)
> >>
> >> >> [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!
> >>
> >> 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.
> >>
> >> > So, everything except a delete can include properties and they all
> >> > work the same way. Correct?
> >>
> >> Yes.
> >>
> >> >>> If a file replace can have a copyfrom source, how does replace with a
> >> >>> copyfrom source differ from add with a copyfrom source?
> >> >>
> >> >> The differ only in the fact that a replace implies the simultaneous deletion
> >> >> of some other object which previously lived at that path.
> >> >
> >> > Got it. That case I understand, it's how they differ in the non-copyfrom
> >> > case that still confuses me.
> >>
> >> This is replace without copyfrom:
> >>
> >> $ svn rm some/file.txt
> >> $ touch some/file.txt
> >> $ svn add some/file.txt
> >> $ svn ci -m "Replace some/file.txt with a new file."
> >>
> >> This is replace with copyfrom:
> >>
> >> $ svn rm some/file.txt
> >> $ touch some/file.txt
> >> $ svn copy someother/differentfile.txt some/file.txt
> >> $ svn ci -m "Replace some/file.txt with a copy of a different file ."
> >
> > And:
> >
> > $ svn rm some/file.txt
> > $ touch some/file.txt
> > $ svn copy some/file.txt@HEAD some/file.txt
> > $ svn ci -m "Replace some/file.txt with a copy itself."
>
> And even:
>
> $ svn mv some/file.txt some/otherfile.txt
> $ svn mv some/otherfile.txt some/file.txt
> $ svn ci -m "Replace some/file.txt with a copy of itself."
>
> (pre-1.7 this would be a replace without copyfrom, breaking the line
> of history [1], but that is fixed as of 1.7)
>
But the fix is client-side, right? One can still do things like that by
driving an RA commit editor directly.
> [1] http://subversion.tigris.org/issues/show_bug.cgi?id=3429 - "svn mv
> A B; svn mv B A" generates replace without history
>
> --
> Johan
Re: Problems with the documentation of Subversion dump format
Posted by Johan Corveleyn <jc...@gmail.com>.
On Tue, Dec 13, 2011 at 8:16 PM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> C. Michael Pilato wrote on Tue, Dec 13, 2011 at 14:01:45 -0500:
>> On 12/13/2011 01:25 PM, Eric S. Raymond wrote:
>> > C. Michael Pilato <cm...@collab.net>:
>> >>> Does a file replace differ in any way from a delete plus add of the new text?
>> >>
>> >> In Subversion, yes. A replacement is, like an add or a delete, an operation
>> >> at the node level, not an operation on the contents of that node. A replace
>> >> is an addition of a new object[1] -- with its own new line of version
>> >> control history -- that is coincidental with the removal of some previously
>> >> existing object that occupied the same path.
>> >
>> > I still don't understand how this differs from a delete followed by an add.
>> > Explain it to me like I'm reallllyyy stuuupid, please, so I can document it
>> > and you never have to explain it again.
>> >
>> > When I add a file at a given path, it creates new object with a
>> > history that is tracked. When I delete that path, I destroy the
>> > container as well as the content. If I subsequently create a new
>> > file at the same path, it's a new object with its own history.
>> >
>> > How is a replace different?
>>
>> Assume your "delete" and subsequent "add" happens in the same commit, it's
>> not different at all. In fact, the Subversion filesystem API doesn't even
>> recognize a "replace" operation. There's "delete (file or dir)", there's
>> "make file" and "make dir", and there's "copy (file or dir)". 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. We favor the likes of:
>>
>> R /some/file.txt
>>
>> over:
>>
>> D /some/file.txt
>> A /some/file.txt
>>
>> in output.
>>
>> (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.)
>>
>> >> [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!
>>
>> 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.
>>
>> > So, everything except a delete can include properties and they all
>> > work the same way. Correct?
>>
>> Yes.
>>
>> >>> If a file replace can have a copyfrom source, how does replace with a
>> >>> copyfrom source differ from add with a copyfrom source?
>> >>
>> >> The differ only in the fact that a replace implies the simultaneous deletion
>> >> of some other object which previously lived at that path.
>> >
>> > Got it. That case I understand, it's how they differ in the non-copyfrom
>> > case that still confuses me.
>>
>> This is replace without copyfrom:
>>
>> $ svn rm some/file.txt
>> $ touch some/file.txt
>> $ svn add some/file.txt
>> $ svn ci -m "Replace some/file.txt with a new file."
>>
>> This is replace with copyfrom:
>>
>> $ svn rm some/file.txt
>> $ touch some/file.txt
>> $ svn copy someother/differentfile.txt some/file.txt
>> $ svn ci -m "Replace some/file.txt with a copy of a different file ."
>
> And:
>
> $ svn rm some/file.txt
> $ touch some/file.txt
> $ svn copy some/file.txt@HEAD some/file.txt
> $ svn ci -m "Replace some/file.txt with a copy itself."
And even:
$ svn mv some/file.txt some/otherfile.txt
$ svn mv some/otherfile.txt some/file.txt
$ svn ci -m "Replace some/file.txt with a copy of itself."
(pre-1.7 this would be a replace without copyfrom, breaking the line
of history [1], but that is fixed as of 1.7)
[1] http://subversion.tigris.org/issues/show_bug.cgi?id=3429 - "svn mv
A B; svn mv B A" generates replace without history
--
Johan
Re: Problems with the documentation of Subversion dump format
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
C. Michael Pilato wrote on Tue, Dec 13, 2011 at 14:01:45 -0500:
> On 12/13/2011 01:25 PM, Eric S. Raymond wrote:
> > C. Michael Pilato <cm...@collab.net>:
> >>> Does a file replace differ in any way from a delete plus add of the new text?
> >>
> >> In Subversion, yes. A replacement is, like an add or a delete, an operation
> >> at the node level, not an operation on the contents of that node. A replace
> >> is an addition of a new object[1] -- with its own new line of version
> >> control history -- that is coincidental with the removal of some previously
> >> existing object that occupied the same path.
> >
> > I still don't understand how this differs from a delete followed by an add.
> > Explain it to me like I'm reallllyyy stuuupid, please, so I can document it
> > and you never have to explain it again.
> >
> > When I add a file at a given path, it creates new object with a
> > history that is tracked. When I delete that path, I destroy the
> > container as well as the content. If I subsequently create a new
> > file at the same path, it's a new object with its own history.
> >
> > How is a replace different?
>
> Assume your "delete" and subsequent "add" happens in the same commit, it's
> not different at all. In fact, the Subversion filesystem API doesn't even
> recognize a "replace" operation. There's "delete (file or dir)", there's
> "make file" and "make dir", and there's "copy (file or dir)". 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. We favor the likes of:
>
> R /some/file.txt
>
> over:
>
> D /some/file.txt
> A /some/file.txt
>
> in output.
>
> (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.)
>
> >> [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!
>
> 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.
>
> > So, everything except a delete can include properties and they all
> > work the same way. Correct?
>
> Yes.
>
> >>> If a file replace can have a copyfrom source, how does replace with a
> >>> copyfrom source differ from add with a copyfrom source?
> >>
> >> The differ only in the fact that a replace implies the simultaneous deletion
> >> of some other object which previously lived at that path.
> >
> > Got it. That case I understand, it's how they differ in the non-copyfrom
> > case that still confuses me.
>
> This is replace without copyfrom:
>
> $ svn rm some/file.txt
> $ touch some/file.txt
> $ svn add some/file.txt
> $ svn ci -m "Replace some/file.txt with a new file."
>
> This is replace with copyfrom:
>
> $ svn rm some/file.txt
> $ touch some/file.txt
> $ svn copy someother/differentfile.txt some/file.txt
> $ svn ci -m "Replace some/file.txt with a copy of a different file ."
And:
$ svn rm some/file.txt
$ touch some/file.txt
$ svn copy some/file.txt@HEAD some/file.txt
$ svn ci -m "Replace some/file.txt with a copy itself."
Re: Problems with the documentation of Subversion dump format
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 12/13/2011 01:25 PM, Eric S. Raymond wrote:
> C. Michael Pilato <cm...@collab.net>:
>>> Does a file replace differ in any way from a delete plus add of the new text?
>>
>> In Subversion, yes. A replacement is, like an add or a delete, an operation
>> at the node level, not an operation on the contents of that node. A replace
>> is an addition of a new object[1] -- with its own new line of version
>> control history -- that is coincidental with the removal of some previously
>> existing object that occupied the same path.
>
> I still don't understand how this differs from a delete followed by an add.
> Explain it to me like I'm reallllyyy stuuupid, please, so I can document it
> and you never have to explain it again.
>
> When I add a file at a given path, it creates new object with a
> history that is tracked. When I delete that path, I destroy the
> container as well as the content. If I subsequently create a new
> file at the same path, it's a new object with its own history.
>
> How is a replace different?
Assume your "delete" and subsequent "add" happens in the same commit, it's
not different at all. In fact, the Subversion filesystem API doesn't even
recognize a "replace" operation. There's "delete (file or dir)", there's
"make file" and "make dir", and there's "copy (file or dir)". 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. We favor the likes of:
R /some/file.txt
over:
D /some/file.txt
A /some/file.txt
in output.
(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.)
>> [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!
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.
> So, everything except a delete can include properties and they all
> work the same way. Correct?
Yes.
>>> If a file replace can have a copyfrom source, how does replace with a
>>> copyfrom source differ from add with a copyfrom source?
>>
>> The differ only in the fact that a replace implies the simultaneous deletion
>> of some other object which previously lived at that path.
>
> Got it. That case I understand, it's how they differ in the non-copyfrom
> case that still confuses me.
This is replace without copyfrom:
$ svn rm some/file.txt
$ touch some/file.txt
$ svn add some/file.txt
$ svn ci -m "Replace some/file.txt with a new file."
This is replace with copyfrom:
$ svn rm some/file.txt
$ touch some/file.txt
$ svn copy someother/differentfile.txt some/file.txt
$ svn ci -m "Replace some/file.txt with a copy of a different file ."
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Problems with the documentation of Subversion dump format
Posted by "Eric S. Raymond" <es...@thyrsus.com>.
C. Michael Pilato <cm...@collab.net>:
> > Does a file replace differ in any way from a delete plus add of the new text?
>
> In Subversion, yes. A replacement is, like an add or a delete, an operation
> at the node level, not an operation on the contents of that node. A replace
> is an addition of a new object[1] -- with its own new line of version
> control history -- that is coincidental with the removal of some previously
> existing object that occupied the same path.
I still don't understand how this differs from a delete followed by an add.
Explain it to me like I'm reallllyyy stuuupid, please, so I can document it
and you never have to explain it again.
When I add a file at a given path, it creates new object with a
history that is tracked. When I delete that path, I destroy the
container as well as the content. If I subsequently create a new
file at the same path, it's a new object with its own history.
How is a replace different?
> [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?
> > Can a replace include a property section?
>
> Yes.
So, everything except a delete can include properties and they all
work the same way. Correct?
> > Does a replace always have text associated with it, or can it have a
> > copyfrom source?
>
> You can have a replace with a copyfrom source (a "replace with history", as
> we call it). You can even have a replace with a copyfrom source *and* text,
> such as would result from this on the client side:
>
> $ svn rm dir/file.txt
> $ svn cp otherdir/otherfile.txt dir/file.txt
> $ echo "Replacement text" > dir/file.txt
> $ svn ci -m "Replace dir/file.txt with a copy of otherdir/otherfile.txt\
> and replace its text, too."
I'll include this in the document I'm working up.
> > If a file replace can have a copyfrom source, how does replace with a
> > copyfrom source differ from add with a copyfrom source?
>
> The differ only in the fact that a replace implies the simultaneous deletion
> of some other object which previously lived at that path.
Got it. That case I understand, it's how they differ in the non-copyfrom
case that still confuses me.
> > How does a "change" differ from a "replace"? My guess is that
> > "change" is issued for nodes that are pure property changes with no
> > file content changes; is this correct?
>
> You are correct.
OK.
I'm working up a second, more formal draft of the dumpfile description.
I'll post it here for review.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
Re: Problems with the documentation of Subversion dump format
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 12/13/2011 09:44 AM, Eric S. Raymond wrote:
> Philip Martin <ph...@wandisco.com>:
>> esr@thyrsus.com (Eric S. Raymond) writes:
>>
>>> # The "replace" action [?is only issued with directory copies, and?]
>>> # signifies that the existing contents of the directory should be
>>> # removed before the copy.
>>
>> Replace applies to files as well.
>
> Does a file replace differ in any way from a delete plus add of the new text?
In Subversion, yes. A replacement is, like an add or a delete, an operation
at the node level, not an operation on the contents of that node. A replace
is an addition of a new object[1] -- with its own new line of version
control history -- that is coincidental with the removal of some previously
existing object that occupied the same path.
[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.
> Can a replace include a property section?
Yes.
> Does a replace always have text associated with it, or can it have a
> copyfrom source?
You can have a replace with a copyfrom source (a "replace with history", as
we call it). You can even have a replace with a copyfrom source *and* text,
such as would result from this on the client side:
$ svn rm dir/file.txt
$ svn cp otherdir/otherfile.txt dir/file.txt
$ echo "Replacement text" > dir/file.txt
$ svn ci -m "Replace dir/file.txt with a copy of otherdir/otherfile.txt\
and replace its text, too."
> If a file replace can have a copyfrom source, how does replace with a
> copyfrom source differ from add with a copyfrom source?
The differ only in the fact that a replace implies the simultaneous deletion
of some other object which previously lived at that path.
> How does a "change" differ from a "replace"? My guess is that
> "change" is issued for nodes that are pure property changes with no
> file content changes; is this correct?
You are correct.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Problems with the documentation of Subversion dump format
Posted by "Eric S. Raymond" <es...@thyrsus.com>.
Philip Martin <ph...@wandisco.com>:
> esr@thyrsus.com (Eric S. Raymond) writes:
>
> > # The "replace" action [?is only issued with directory copies, and?]
> > # signifies that the existing contents of the directory should be
> > # removed before the copy.
>
> Replace applies to files as well.
Does a file replace differ in any way from a delete plus add of the new text?
Can a replace include a property section?
Does a replace always have text associated with it, or can it have a
copyfrom source?
If a file replace can have a copyfrom source, how does replace with a
copyfrom source differ from add with a copyfrom source?
How does a "change" differ from a "replace"? My guess is that
"change" is issued for nodes that are pure property changes with no
file content changes; is this correct?
For each of the actions, it needs to be clear
* whether it can have a text section
* whether it can have a copyfrom source
* whether it can have a property section
* whether it can be a file operation, a directory operation, or both.
The yes-or-no answers to those questions alone imply 36 different
possible semantic cases. There are probably simplifying rules like
"anything that can have a text section can have a file copyfrom
source" or "any file operation except a delete can have a proerty
section", but the existing notes don't really make any of these clear.
To understand this, I'm reduced to groveling through megabytes of
dumpfiles, trying to figure out all the corner cases by eyeball. This
means the documentation isn't good enough; the syntax of dumpfiles is
beautifully designed but the semantics is pretty murky.
> > # Interpreting copyfrom_path for file copies is straightforward; the
> > # target pathname gets the contents of the source pathname.
> > #
> > # Directory copies (the primitive beneath branching and tagging) are
> > # tricky. For each source path under the source directory, a new path
> > # is generated by removing the head segment of the pathname that is
> > # the source directory. That new path under the target directory gets
> > # the content of the source path.
>
> Not sure what this means. This copies A/B/C to X/Y/Z:
>
> Node-path: X/Y/Z
> Node-kind: dir
> Node-action: add
> Node-copyfrom-rev: 10
> Node-copyfrom-path: A/B/C
I meant that, given this:
> Node-path: x/y/z
> Node-kind: dir
> Node-action: add
> Node-copyfrom-rev: 10
> Node-copyfrom-path: a/b/c
a file a/b/c/d will be copied to x/y/z/d. The "a/b/c" is what I was calling
the "head segment".
If that's not the way it's supposed to work, how is it supposed to worl?
> > # A single revision may include multiple copyfrom nodes, even multiple
> > # copyfroms to the same directory, even mixed directory and file copies
> > # to the same directory; [?Subversion client tools never generate such
> > # mixed copies, but?] I have seen the results of cvs2svn doing it.
>
> Not sure what "mixed directory and file copies to the same directory"
> means or why Subversion clients would be restricted. Given directories
> D1 and D2 and a file F it's trivial to copy D1 to D2/Dnew and F to
> D2/Fnew.
Yes, but in a single copy command? My experience is that every one copy
operation done from the CLI triggers a commit.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>