[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: David Glasser <glasser_at_davidglasser.net>
Date: Thu, 18 Sep 2008 13:38:11 -0400

I don't even know that "opening a single database" is an advantage: it
has implications for concurrency between operations on completely
separate working copies.

--dave

On Wed, Sep 17, 2008 at 11:01 AM, Greg Stein <gstein_at_gmail.com> wrote:
> Combining/sharing the blob-store and the metadata that defines it is
> the biggest one. But we could potentially share all data about the
> BASE tree. If the same node <uuid, path, rev> occurs in multiple
> working copies, then information about the text and props can be
> shared.
>
> I believe and agree with you that there is little benefit in putting
> all the WORKING trees into one database, beyond the small advantage of
> opening a single database.
>
> Cheers,
> -g
>
> On Wed, Sep 17, 2008 at 7:07 AM, David Glasser <glasser_at_davidglasser.net> wrote:
>> On Wed, Sep 17, 2008 at 7:29 AM, Greg Stein <gstein_at_gmail.com> wrote:
>>> On Wed, Sep 17, 2008 at 3:34 AM, Vincent Lefevre <vincent+svn_at_vinc17.org> wrote:
>>>> On 2008-09-15 05:17:25 -0700, Greg Stein wrote:
>>>>> If it is renamed, then you've just "lost" your metadata. The metadata
>>>>> is tied to an absolute path.
>>>>
>>>> An absolute path? This would be annoying because the path to my NFS
>>>> home depends on the machine from which I have access.
>>>
>>> If there are no .svn directories in your working copy, then it looks
>>> like any other directory. The only way for svn to know it's a working
>>> copy is to hold a reference to its absolute path.
>>>
>>> That said, we've also been discussing how to drop a unique identify
>>> into (say) .svn/wc-id at the root of your working copy. There are some
>>> potential issues with that, however. When svn sees the working copy at
>>> a new path, it won't necessarily know if it was simply moved or
>>> copied, and (thus) how to handle the metadata that it has recorded for
>>> that working copy.
>>>
>>> In your situation, you'd simply want to keep the metadata in the
>>> wcroot, rather than a centralized location. If all the data is in
>>> wcroot/.svn/, then svn will not worry about the absolute path at all.
>>
>> As this thread has gone on, I think I've lost track of the motivation
>> for centralizing the metadata beyond just the working copy root. I
>> understand wanting to be able to (optionally) centralize and share the
>> blob-store (since file contents/etc are likely to be shared between
>> multiple working copies), but what is the gain of combining the actual
>> working copy metadata itself? (More than "you can control where it
>> sits", which you can also do by replacing the .svn directory with a
>> symlink.)
>>
>> --dave
>>
>> --
>> David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
>>
>

-- 
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
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-18 19:38:26 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.