[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: Greg Stein <gstein_at_gmail.com>
Date: Thu, 18 Sep 2008 13:49:22 -0400

There are no concerns around concurrency. The typical working copy is
used by only one person at a time. Same for a central datastore
covering multiple working copies. For shared working copies, the
potential for contention is ridiculously small.

Regardless, SQLite will handle the concurrency issues.


On Sep 18, 2008, at 13:38, "David Glasser" <glasser_at_davidglasser.net>

> 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_at_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:49:50 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.