I'm referring to a single person working in multiple working copies at
once: doing a huge checkout while working in a second wc, for example.
Not necessarily everyday behavior, but far more reasonable than the
other edge cases brought up in this thread.
--dave
On Thu, Sep 18, 2008 at 1:49 PM, Greg Stein <gstein_at_gmail.com> wrote:
> 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@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 20:16:57 CEST