Kumaran Santhanam wrote:
[snip]
>>>2) Explicit edit support
>>
>>Although still subject to the constraints above, this feature is
>>relatively high on the list of things to add post-1.0. It is a
>>necessary step along the way to explicit locking support, could help us
>>support much faster working directory crawls (faster status, diff,
>>commit, etc.), and could help eliminate the text-base penalty without
>>sacrificing network bandwidth.
>>
>>(Of course, it would have to be an option; the CVS "always-writable"
>>model is very convenient for some developers. I'm thinking rather than
>>a config file option, it would be a checkout option, with some
>>corresponding metadata in .svn/entries. Though there could be a config
>>option to set the default checkout behavior, I suppose.)
>
>
> Same comment as 1) above: I'm hoping that it should not take
> much code to do this in a basic way:
>
> - svn edit is simply 'chmod +w FILE'
> - svn revert has to do 'chmod -w FILE'
> - svn commit has to do 'chmod -w FILE'
> - svn update has to bring it in as read-only
> - svn status has to check file permissions to get the 'U' tag
>
> If there is anything I'm missing, do let me know. Again, this is
> a feature I need right away, so I'm probably going to have to
> make the patch, at least on a private copy.
>
[snip]
I looked at this a little also (we ended up using properties to keep
people from committing if they don't have reserve-required item
reserved). There are a number of other places you'll have to make sure
read-only-ness is turned off temporarily, also, of course -- such as
updates, merges, post-commit updates, and probably more.
DJ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Aug 23 03:38:37 2003