[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-11 23:05:35 CET

Greg Stein wrote:

> On Sat, Feb 10, 2001 at 07:35:54AM -0600, Ben Collins-Sussman wrote:
>
>> Branko =?ISO-8859-2?Q?=C8ibej?= <brane@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:   <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.