[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: CVS update: subversion/subversion/libsvn_fs structure

From: Branko Èibej <brane_at_xbc.nu>
Date: 2001-02-10 13:15:11 CET

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:   <brane_at_xbc.nu>             http://www.xbc.nu/brane/
    work:   <branko.cibej_at_hermes.si>   http://www.hermes-softlab.com/
     ACM:   <brane_at_acm.org>            http://www.acm.org/
Received on Sat Oct 21 14:36:21 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.