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.
Cheers,
-g
On Sep 18, 2008, at 13:38, "David Glasser" <glasser_at_davidglasser.net>
wrote:
> 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