+1 to supporting working copies with multiple users. It's not my
preferred mode of operation, but due to reasons outside my control, we
rely on this ability and removing it would cause problems.
On Sep 15, 2008, at 6:56 PM, Greg Stein wrote:
> I was hoping to drop that "feature" :-)
> It shouldn't be hard to maintain, though, since sqlite handles most
> of it. I'll only need to be careful around writing a new base into
> the datastore.
> On Sep 15, 2008, at 18:43, Garance A Drosihn <drosih_at_rpi.edu> wrote:
>> At 11:56 PM +0200 9/15/08, Stefan Sperling wrote:
>>> On Mon, Sep 15, 2008 at 05:20:31PM -0400, Garance A Drosihn wrote:
>>>> At 8:48 PM -0700 9/14/08, Greg Stein wrote:
>>>>> There are basically three options:
>>>>> 1) at the root of the working copy, in a .svn subdirectory
>>>>> 2) in a subdir of ~/.subversion/
>>>>> 3) in a directory specified by your config (and/or an environ
>>>>> I'm leaning more and more towards making option (2) be the default
>>>>> because of the advantages of sharing text bases. At first, I was
>>>>> thinking (1) would be the default.
>>>> I'd think that (1) would be the better default. What happens if
>>> > multiple people might be using a single working copy?
>>> I'd consider sharing a single working copy between multiple users
>>> a somewhat exotic use case. At least more exotic than the use case
>>> of every user owning their own working copies -- in which case
>>> (2) is clearly the better option.
>> Hmm. It also occurs to me that the one of the side-effects of
>> how we work is that we aren't often checking out new working
>> copies. I guess this isn't as big of an issue as I first thought
>> it might be. Let me just ask that the new code will still support
>> WC's which are used among multiple people (for those who need to
>> work that way), but I agree that that ability need not influence
>> the default behavior of svn.
>> Garance Alistair Drosehn = gad_at_gilead.netel.rpi.edu
>> Senior Systems Programmer or gad_at_freebsd.org
>> Rensselaer Polytechnic Institute or drosih_at_rpi.edu
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-16 15:20:48 CEST