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

Re: svn commit: r39733 - in trunk/subversion: include/private libsvn_client libsvn_wc tests/cmdline

From: Greg Stein <gstein_at_gmail.com>
Date: Tue, 20 Oct 2009 14:12:26 -0400

On Thu, Oct 1, 2009 at 09:47, Julian Foad <julianfoad_at_btopenworld.com> wrote:
> On Thu, 2009-10-01 at 14:40 +0100, Julian Foad wrote:
>> On Thu, 2009-10-01 at 05:44 -0700, Bert Huijben wrote:
>> > Author: rhuijben
>> > Date: Thu Oct  1 05:44:40 2009
>> > New Revision: 39733
>> >
>> > Log:
>> > Following up on r39729, fix the 'tree conflicts: tree missing, leaf del'
>> > test by adding a temporary api for checking on working copy obstructions.
>> >
>> > Note that this class of obstructions will be gone once we move to a
>> > central db.
>>
>> Why/how won't it be possible for a node to be obstructed?
>
> I see you replaced this change with something different in r39737, but
> the new version says in obstructed_or_missing(),
>
> +  /* ### This check (and most of this function)
> +         can be removed after we move to one DB */
>
> Can you help me understand why?

In wc-1, a versioned subdirectory can become "obstructed" by rm'ing
the directory and/or dropping a file in its place. The parent
directory has a record of the versioned-subdir, but we (no longer)
have access to its metadata.

In wc-ng, all the metadata is recorded "at the top", so we'll always
have all the metadata for the subdir. In fact, if it is missing, we
can completely restore the entire missing subtree from our central
store of pristines(!).

Now, it is true that we can still have file-vs-dir obstructions in the
working copy that are unrecorded ("what? I see a subdir, but that's
supposed to be a file").

>...

Cheers,
-g

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2409481
Received on 2009-10-20 20:12:44 CEST

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