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

Re: Base text files, re: IRC chat

From: Listman <listman_at_burble.net>
Date: Mon, 15 Sep 2008 08:04:02 -0700

On Sep 15, 2008, at 5:32 AM- Sep 15, 2008, Daniel Shahaf wrote:

> Greg Stein wrote on Mon, 15 Sep 2008 at 05:17 -0700:
>> On Mon, Sep 15, 2008 at 5:07 AM, Daniel Shahaf <d.s_at_daniel.shahaf.name
>> > wrote:
>>> Greg Stein wrote on Mon, 15 Sep 2008 at 04:29 -0700:
>>>> That's a good point. I was thinking that it wouldn't be a big
>>>> deal...
>>>> svn can easily track the references. But I guess not so much if you
>>>> just blast the WC out from under it :-P
>>> And what if, rather than blasted away, the WC was renamed or
>>> duplicated
>>> (causing the reference count to be lower than actuality)? How do you
>>> fix the reference counts then?
>> If it is renamed, then you've just "lost" your metadata. The metadata
>> is tied to an absolute path.
> Ah, so the "metadata" completely replaces .svn dirs? I thought just
> the
> text-bases would be centralised.

unfortunately there's a number of non-cooperative tools (most of which
we seem to use :(
that just delete the .svn dirs during their operation and break our
working copies. centralizing
*ALL* the metadata gets my vote..

>> It seems possible to have some admin command to notify svn that you
>> renamed the directory, but I'd rather just say "don't do that, or
>> keep
>> the metadata inside the WC if you're gonna move it around." Same
>> thing
>> goes for copies.
> So if you want to rename a WC, you have to run 'checkout' again? The
> latter would take too long; it could be faster to edit the metadata
> manually than to run checkout from scratch :)

renaming doesn't happen very often, this is a corner case IMHO and
shouldn't have a big
say in what we do here.


To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-09-15 17:04:25 CEST

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.