You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Greg Stein <gs...@lyra.org> on 2001/02/10 03:23:28 UTC
Re: CVS update: subversion/subversion/libsvn_fs structure
On Sat, Feb 10, 2001 at 01:46:55AM -0000, brane@tigris.org wrote:
>...
> +COPY: how copied nodes are represented.
> +
> +If the header's KIND is "copy", then the node-revision skel represente
> +a copy of another node, and has the form:
> +
> + (HEADER SOURCE-REVISION (NAME ...))
> +
> +where SOURCE-REVISION is a filesystem revision, and (NAME ...) is a
> +list of directory entry names (the path) that identifies the copy
> +source in this revision. The copy source may not be a mutable node.
$ svn add foo.c
$ svn cp foo.c bar.c
$ svn commit
I'd say that the copy source is a mutable node in this scenario :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: CVS update: subversion/subversion/libsvn_fs structure
Posted by Branko Čibej <br...@xbc.nu>.
Greg Stein wrote:
> On Sat, Feb 10, 2001 at 07:35:54AM -0600, Ben Collins-Sussman wrote:
>
>> Branko =?ISO-8859-2?Q?=C8ibej?= <br...@xbc.nu> writes:
>> ...
>>
>>> An "svn cp" from a source that has been added but not committed can only
>>> mean "cp; svn add". I hope.
>>
>> Exactly.
>
>
> What the justification for that behavior? Or are you just calling it "too
> hard" and punting?
>
> If I add a file, then copy to another location, then that is meaningful
> information. The history would show that, and deltas/merging could be
> possible (where they possibly couldn't be if the tracking wasn't there).
>
> There is a meaningful and obvious/intuitive semantic. Question is whether we
> can handle it.
I'm sure we could handle it (although it would be a bit complex), but
why bother? If you need that kind of history, you can always commit
before the add. Otherwise you'd have to store history locally, which you
definitely don't want to do. Imagine this:
$ svn add foo.c
$ svn cp foo.c bar.c
$ svn mv foo.c baz.c
$ svn commit
At the commit, you'd have to know that bar.c is a copy of baz.c, not
foo.c. This means that every change to a file would have to be reflected
to all its copies. You'd have the same problem if you allowed copies of
mutable nodes in the filesystem.
All of this can be done, of course; but I don't think it's worth the
trouble. If you need the history, just commit more often. That's what
the repository's for, after all.
--
Brane �ibej
home: <br...@xbc.nu> http://www.xbc.nu/brane/
work: <br...@hermes.si> http://www.hermes-softlab.com/
ACM: <br...@acm.org> http://www.acm.org/
Re: CVS update: subversion/subversion/libsvn_fs structure
Posted by Greg Stein <gs...@lyra.org>.
On Sat, Feb 10, 2001 at 07:35:54AM -0600, Ben Collins-Sussman wrote:
> Branko =?ISO-8859-2?Q?=C8ibej?= <br...@xbc.nu> writes:
>...
> > An "svn cp" from a source that has been added but not committed can only
> > mean "cp; svn add". I hope.
>
> Exactly.
What the justification for that behavior? Or are you just calling it "too
hard" and punting?
If I add a file, then copy to another location, then that is meaningful
information. The history would show that, and deltas/merging could be
possible (where they possibly couldn't be if the tracking wasn't there).
There is a meaningful and obvious/intuitive semantic. Question is whether we
can handle it.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: CVS update: subversion/subversion/libsvn_fs structure
Posted by Ben Collins-Sussman <su...@newton.ch.collab.net>.
Branko =?ISO-8859-2?Q?=C8ibej?= <br...@xbc.nu> writes:
> $ svn add foo.c
> $ svn rm foo.c
> $ svn commit
>
> I'd say that /this/ sequence is as much a PITA as yours. :-)
I recently spent a week handling cases like this in the WC.
In the case above, the `add' call creates a new entry in the entries
file marked for addition, and the `rm' call removes the entry
completely; so the commit has no idea it ever happened.
I also handle a case like this:
$ svn rm foo.c
$ touch foo.c
$ svn add foo.c
This marks foo.c for *both* deletion and addition, and when driving
the commit editor, the delete and then the add happen in exactly that
order.
Here's another weird case we handle:
$ svn rm foo.c
$ touch foo.c
$ svn add foo.c
$ svn rm foo.c
In this case, the last command just unsets the `add' flag in the
entry, leaving just a `delete' flag left.
Fun, isn't this? :)
> An "svn cp" from a source that has been added but not committed can only
> mean "cp; svn add". I hope.
Exactly.
Re: CVS update: subversion/subversion/libsvn_fs structure
Posted by Branko Čibej <br...@xbc.nu>.
Greg Stein wrote:
> On Sat, Feb 10, 2001 at 01:46:55AM -0000, brane@tigris.org wrote:
>
>> ...
>> +COPY: how copied nodes are represented.
>> +
>> +If the header's KIND is "copy", then the node-revision skel represente
>> +a copy of another node, and has the form:
>> +
>> + (HEADER SOURCE-REVISION (NAME ...))
>> +
>> +where SOURCE-REVISION is a filesystem revision, and (NAME ...) is a
>> +list of directory entry names (the path) that identifies the copy
>> +source in this revision. The copy source may not be a mutable node.
>
>
> $ svn add foo.c
> $ svn cp foo.c bar.c
> $ svn commit
>
> I'd say that the copy source is a mutable node in this scenario :-)
$ svn add foo.c
$ svn rm foo.c
$ svn commit
I'd say that /this/ sequence is as much a PITA as yours. :-)
Anyway: a "svn add" without a commit is strictly a WC operation, it
doesn't create any mutable nodes in the filesystem. Since you can't know
the sequence of edits during the commit, you could get the "add bar.c
with ancestor foo.c" before the "add foo.c", which is nonsense. Or do
you propose the WC keep track of such dependencies and tell the commit
editor about them somehow? Eek ...
An "svn cp" from a source that has been added but not committed can only
mean "cp; svn add". I hope.
--
Brane �ibej
home: <br...@xbc.nu> http://www.xbc.nu/brane/
work: <br...@hermes.si> http://www.hermes-softlab.com/
ACM: <br...@acm.org> http://www.acm.org/
Re: CVS update: subversion/subversion/libsvn_fs structure
Posted by Jim Blandy <ji...@zwingli.cygnus.com>.
Greg Stein <gs...@lyra.org> writes:
> On Sat, Feb 10, 2001 at 01:46:55AM -0000, brane@tigris.org wrote:
> >...
> > +COPY: how copied nodes are represented.
> > +
> > +If the header's KIND is "copy", then the node-revision skel represente
> > +a copy of another node, and has the form:
> > +
> > + (HEADER SOURCE-REVISION (NAME ...))
> > +
> > +where SOURCE-REVISION is a filesystem revision, and (NAME ...) is a
> > +list of directory entry names (the path) that identifies the copy
> > +source in this revision. The copy source may not be a mutable node.
>
> $ svn add foo.c
> $ svn cp foo.c bar.c
> $ svn commit
>
> I'd say that the copy source is a mutable node in this scenario :-)
No --- the source of a copy node can never be a mutable node, because
changes to the original mustn't affect the copy. You can't do the
"copy-is-reference" trick if the original is mutable. When we copy
mutable nodes, we really copy them, and record the information some
other way.