Re: Feature Ideas

>>>2) Explicit edit support

Kumaran Santhanam wrote:
>
> 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.

I am interested to know why explicit editing is useful and important to you.

You appear to be describing the sort of interface that would be used with an exclusive locking mechanism, but not proposing to design or implement the actual locking (which needs to involve the server) yet. Please could you say what benefit this will give on its own. It looks to me like it will give the illusion of locking, but without the important part which is: "svn edit: you can't do this yet because someone else is editing the file". The "svn edit" request would always succeed, and only when the user tries to commit the file would they discover that actually someone else had also been editing it. That is what bothers me about this idea.

The only other thing I can see in your proposal is that it gives the user a way to create a list of "interesting" files (svn edit and svn revert) and to display that list (svn status) and to give a warning ("read-only") if he tries to edit a file which he has not already declared as "interesting". This bunch of functionality could be convenient, but is not part of version control unless it is linked to an exlusive locking mechanism. I think from a later message that you have already accepted that this can be done with external scripts.

I feel that exclusive locking is an essential feature for Subversion to aquire, but that creating the user interface before designing the feature is a bad way to start.

Or am I missing the point of this feature?

Greg Hudson wrote (previously):
>>
>>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,

Some such interface would certainly be a part of explicit locking support, but I'm not sure that it makes sense "along the way".

>> 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.

Yes, these are two nice side effects.

- Julian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Aug 28 15:32:17 2003