On Apr 2, 2005, at 5:33 PM, Patrick Burleson wrote:
> On Apr 2, 2005 5:25 PM, Ben Collins-Sussman <sussman@collab.net> wrote:
>>
>> No, because 'svn lock' prevents others from committing. The original
>> poster said he doesn't want to disable concurrency, he just wants
>> people to have to declare their intent to edit.
>
> I could see this being a fairly useful feature in some development
> environments. And it could all be done client side. Maybe something in
> the config file to turn on default "read-only" checkouts. Then a
> simple "edit" command to make them read only. (Not trying to imply
> that it would be a simple thing to implement, just a simple command)
As far as use cases go, I can think of one where this might be useful
(particularly in conjunction with the large-WC time issue for svn
status)--some development environments and editors have a nasty habit
of changing files silently, often for no apparent reason (e.g. a
machine-generated file, generated by the same program, will move around
two lines without changing either line's content). Or one might have a
large number of files open in an IDE to review calling structures, etc
and accidentally type a single character or a small number of
characters into the wrong window, followed by hitting "Save All" before
exiting. Both of these scenarios can be dealt with via svn status and
then dealing manually with the files that have cosmetic-only changes;
however, it may be helpful in some situations to be able to do an "$
svn checkout -noedit .... " that would provide read-only files
(leveraging the OS's ability to mark them that way) and then mark, in
the WC, that svn can assume all directories so marked have not changed
since checkout. Doing an " $ svn edit /filename/" would then cause
that file and the appropriate directory tree up to that file (from the
root of the WC) to be marked as possibly-changed, which could be
toggled with " $ svn edit ... " and " $ svn noedit ... ".
(my two cents. But on a slightly different note, many thanks to the
dev team for the functionality that is available...having an
inexpensive and generally easy-to-install versioning system available
makes my life a lot easier.)
Kevin Broderick, Bolton Valley IT Department
kbroderick@boltonvalley.com / 802.434.6807 (V) / 802.329.6807 (F)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun Apr 3 17:42:11 2005