[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: performance enhancement by working copy svn server

From: Garance A Drosihn <drosih_at_rpi.edu>
Date: Sat, 12 Apr 2008 17:24:17 -0400

At 5:16 PM -0400 4/12/08, Garance A Drosihn wrote:
>At 3:00 PM -0400 4/10/08, Harvey, Edward wrote:
>> > The whole working copy would have
>>> read-only permissions set by default; 'svn edit' would make
>>> a file read-write.
>>Actually, I think this sounds very reasonable (as an option; I do
>>respect the need for people to continue working the way they always
>>have before). It's a quick & dirty, easy simple technique to
>>nearly eliminate the whole problem. No architecture dependent
>>(well, minimal) code, which still (usually) creates the ability for
>>the svn client to monitor all the file edits.
>Let me add this observation: You might also need to have directories
>to be marked as read-only by default. There are some commands which
>will alter a file by making changes to a copy of it, and them removing
>the old file by moving in the new file. I've had .svn working copies
>corrupted by this, for instance, even though the *files* in the .svn
>directory are permitted read-only to me.

I better add a bit more to this comment...

I realize that making the directories read-only by default may cause
some headaches for normal use of a working copy. But my point is
that unless you do that, it isn't really safe to assume that the
files in the working copy will not be changed just because we've
added this 'svn edit' trickery that is based solely on chmod bits.

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-04-12 23:24: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.