RE: Re: Checkout every file as read-only; make some of them edita ble with a explicit command.

[Robert Hunter <ro...@gen-i.co.nz>]

Peter Yamamoto wrote:
[...]
> A person who is about to work on a file that cannot be merged (eg binary
> file of some sort such as may art file formats), can exclusively lock it
> before working on it. When this is part of the workflow, it means that
> people won't waste time working on a file only one of them will be able
> to commit.
[...]
> The point is that this "feature" does serve a valid purpose, and the
> version control layer can act as a very good self-defense mechanism. The
> person who does it right and checks out exclusively before working is
> the person who justifiably can check in their work.

As a discussion point, perhaps it would make sense to have an attribute
that controls this. It would be versioned like any other resource,
so you would see the following scenario:

Alice checks out revision 10.
Bob checks out revision 10.
Alice accepts a task that requires modifying a file, "non-versionable.png".
Alice runs an update, but her working copy is already up to date.
Alice sets an attribute "read-only", perhaps with her username as a value.
Alice commits revision 11.
Alice begins working on the file.
Bob accepts a task that requires modifying the same file.
Bob runs an update, and receives the new "read-only" attribute.
Bob's client sets local filesystem permissions on the file to read only.
Bob begins work on the file, but his editor informs him the file is
read-only.
Alice finishes work on the file.
Alice removes the "read-only" attribute.
Alice issues commits revision 12.
Bob updates to revision 12.
Bob's client sets the local filesystem permissions on the file to
read/write.

Apologies for the verbose explanation, but hopefully it will serve as a
concrete
example for discussion.

(I'm sure this has come up before, but it sounds like a doable solution
within
the existing framework...)

-- 
Robert Hunter

*****************************************************************************
This communication, including any attachments, is confidential.
If you are not the intended recipient, you should not read it
- please contact me immediately, destroy it, and do not copy
or use any part of this communication or disclose anything about it,
Thank you.
Please note that this communication does not designate an information system
for the purposes of the Electronic Transactions Act 2002
******************************************************************************

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Checkout every file as read-only; make some of them edita ble with a explicit command.

[Ben Collins-Sussman <su...@collab.net>]

On Nov 17, 2004, at 3:48 PM, Scott Palmer wrote:
> what about a svn 1.0 client using a 'file:' URL on a repository that 
> was created with 1.2 and has 'svn:needs-lock' set on some files?  Will 
> that case be broken?
>

You are correct.  If an svn 1.2 client (linked statically to libsvn_fs 
1.2) creates a lock in the repository database, and then an svn 1.0 
client (linked statically to libsvn_fs 1.0) tries to the change the 
file, it will succeed in ignoring the lock... it won't even know that 
the lock-tables are present.

A good argument not to use file:/// very often, I guess.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Checkout every file as read-only; make some of them edita ble with a explicit command.

[Scott Palmer <sc...@2connected.org>]

On Nov 17, 2004, at 3:53 PM, Ben Collins-Sussman wrote:

>
> On Nov 17, 2004, at 1:34 PM, Scott Palmer wrote:
>>
>> This implies that locking a file will bump the revision number of the 
>> repository, just to change a property.   So editing any file with the 
>> svn:must-lock property results in the repository revision being 
>> incremented twice by the time the changes are checked in.  Correct?  
>> In fact a lock and unlock with no actual changes to the file would 
>> still bump the revision by 2, right?
>
> Let me clarify.
>
> I'm not talking about the 'svn:needs-lock' property getting constantly 
> added and removed or changed.  It's attached to the file *once*, just 
> like 'svn:eol-style' or 'svn:keywords'.  And it stays attached, 
> forever.
>
> When the svn client sees that property, it automatically makes the 
> file 'read-only', all the time.  Only by running 'svn lock' does the 
> file become read-write, and then after the lock is released it goes 
> back to read-only again.  The property isn't changing at all.  The 
> property merely exists as a signal to the svn client, telling the 
> client that this file "should be uneditable, unless your user locks 
> it.".

Ah,  where is the information about "already locked by xxxxxx" stored?

>> Obviously I have an oversimplified view of the problem.

Told ya :)

> Locks are a feature of the filesystem itself:  libsvn_fs.so, and 
> svn_fs.h.  The filesystem API is used to create and destroy them, and 
> they are enforced by the filesystem.

Duh,  of course... I forgot entirely about enforcement issues.  Though, 
it is really my ignorance of how subversion is working under the 
hood...

> If we implemented a locking system that only exited (or were enforced) 
> by svn clients, then any program could easily circumvent them, or even 
> worse -- accidentally ignore them.  You lock a file with svn 1.1 
> client.  Then an svn 1.0 client comes along and changes the file 
> anyway!

Do clients need to know which filesystem is being used?  I guess the 
filesystem API fits in at a different level than I was thinking.   
Since 'file:'  URLs can be used to access the repository... which 
essentially means the "client" is the "server"... so what about a svn 
1.0 client using a 'file:' URL on a repository that was created with 
1.2 and has 'svn:needs-lock' set on some files?  Will that case be 
broken?

Scott



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Checkout every file as read-only; make some of them edita ble with a explicit command.

[Ben Collins-Sussman <su...@collab.net>]

On Nov 17, 2004, at 1:34 PM, Scott Palmer wrote:
>
> This implies that locking a file will bump the revision number of the 
> repository, just to change a property.   So editing any file with the 
> svn:must-lock property results in the repository revision being 
> incremented twice by the time the changes are checked in.  Correct?  
> In fact a lock and unlock with no actual changes to the file would 
> still bump the revision by 2, right?

Let me clarify.

I'm not talking about the 'svn:needs-lock' property getting constantly 
added and removed or changed.  It's attached to the file *once*, just 
like 'svn:eol-style' or 'svn:keywords'.  And it stays attached, 
forever.

When the svn client sees that property, it automatically makes the file 
'read-only', all the time.  Only by running 'svn lock' does the file 
become read-write, and then after the lock is released it goes back to 
read-only again.  The property isn't changing at all.  The property 
merely exists as a signal to the svn client, telling the client that 
this file "should be uneditable, unless your user locks it.".


>
> Ben, you mention in another message ('Re: Checkout every file as 
> read-only; make some of them editable with a explicit command.') that 
> you are working on the locking feature for the BDB back-end.  I'm 
> wondering why the implementation would depend on the back-end at all?  
> It doesn't seem to matter based on the above description.  All the 
> primitive operations that it is built on (setting and getting 
> properties) are already available.   Obviously I have an 
> oversimplified view of the problem.
>

Locks are a feature of the filesystem itself:  libsvn_fs.so, and 
svn_fs.h.  The filesystem API is used to create and destroy them, and 
they are enforced by the filesystem.

If we implemented a locking system that only exited (or were enforced) 
by svn clients, then any program could easily circumvent them, or even 
worse -- accidentally ignore them.  You lock a file with svn 1.1 
client.  Then an svn 1.0 client comes along and changes the file 
anyway!  Whoops.  Also remember that generic DAV clients (which know 
nothing of Subversion) expect the server to able to lock/unlock things.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Checkout every file as read-only; make some of them edita ble with a explicit command.

[Scott Palmer <sc...@2connected.org>]

On Nov 17, 2004, at 1:55 AM, Ben Collins-Sussman wrote:

>
> On Nov 17, 2004, at 12:10 AM, Robert Hunter wrote:
>>
>> ...
>> Alice sets an attribute "read-only", perhaps with her username as a 
>> value.
>> Alice commits revision 11.
>> Alice begins working on the file.
>> Bob accepts a task that requires modifying the same file.
>> Bob runs an update, and receives the new "read-only" attribute.
>> Bob's client sets local filesystem permissions on the file to read 
>> only.
>> Bob begins work on the file, but his editor informs him the file is
>> read-only.
>> Alice finishes work on the file.
>> Alice removes the "read-only" attribute.
>> Alice issues commits revision 12.

> You've effectively just described how our upcoming 1.2 'locking' 
> feature is going to work, the thing I've been working on for the last 
> month or so.

This implies that locking a file will bump the revision number of the 
repository, just to change a property.   So editing any file with the 
svn:must-lock property results in the repository revision being 
incremented twice by the time the changes are checked in.  Correct?  In 
fact a lock and unlock with no actual changes to the file would still 
bump the revision by 2, right?

Ben, you mention in another message ('Re: Checkout every file as 
read-only; make some of them editable with a explicit command.') that 
you are working on the locking feature for the BDB back-end.  I'm 
wondering why the implementation would depend on the back-end at all?  
It doesn't seem to matter based on the above description.  All the 
primitive operations that it is built on (setting and getting 
properties) are already available.   Obviously I have an oversimplified 
view of the problem.


Scott


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Checkout every file as read-only; make some of them edita ble with a explicit command.

[Branko Čibej <br...@xbc.nu>]

Ben Collins-Sussman wrote:

>
> On Nov 17, 2004, at 12:10 AM, Robert Hunter wrote:
>
>>
>> Alice checks out revision 10.
>> Bob checks out revision 10.
>> Alice accepts a task that requires modifying a file, 
>> "non-versionable.png".
>> Alice runs an update, but her working copy is already up to date.
>> Alice sets an attribute "read-only", perhaps with her username as a 
>> value.
>> Alice commits revision 11.
>> Alice begins working on the file.
>> Bob accepts a task that requires modifying the same file.
>> Bob runs an update, and receives the new "read-only" attribute.
>> Bob's client sets local filesystem permissions on the file to read only.
>> Bob begins work on the file, but his editor informs him the file is
>> read-only.
>> Alice finishes work on the file.
>> Alice removes the "read-only" attribute.
>> Alice issues commits revision 12.
>> Bob updates to revision 12.
>> Bob's client sets the local filesystem permissions on the file to
>> read/write.
>>
>
> You've effectively just described how our upcoming 1.2 'locking' 
> feature is going to work, the thing I've been working on for the last 
> month or so.

Not quite. :-) He described how shared locks could concievably work, but 
we punted on shared locks ages ago and decided to only implement 
exclusive locks.

-- Brane



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Checkout every file as read-only; make some of them edita ble with a explicit command.

[Ben Collins-Sussman <su...@collab.net>]

On Nov 17, 2004, at 12:10 AM, Robert Hunter wrote:
>
> Alice checks out revision 10.
> Bob checks out revision 10.
> Alice accepts a task that requires modifying a file, 
> "non-versionable.png".
> Alice runs an update, but her working copy is already up to date.
> Alice sets an attribute "read-only", perhaps with her username as a 
> value.
> Alice commits revision 11.
> Alice begins working on the file.
> Bob accepts a task that requires modifying the same file.
> Bob runs an update, and receives the new "read-only" attribute.
> Bob's client sets local filesystem permissions on the file to read 
> only.
> Bob begins work on the file, but his editor informs him the file is
> read-only.
> Alice finishes work on the file.
> Alice removes the "read-only" attribute.
> Alice issues commits revision 12.
> Bob updates to revision 12.
> Bob's client sets the local filesystem permissions on the file to
> read/write.
>

You've effectively just described how our upcoming 1.2 'locking' 
feature is going to work, the thing I've been working on for the last 
month or so.

However, our UI is just a tiny bit different.  If a file is generally 
unmergeable, then users and admins set a 'svn:must-lock' property on 
it.  When this property is present, the file is read-only all the time, 
for everyone, in every working copy.  The idea is that people will 
notice the read-only-ness in their editor, and it will remind them that 
the file needs to be locked, using an 'svn lock' command.  Once a user 
has locked the file, it becomes read-write for him.  After committing & 
unlocking, it goes back to its normal read-only state.

The theory here is that the everyday read-only state will prevent Bob 
from wasting hours of work before he ever begins;  the file is 
uneditable, and when he runs 'svn lock' to make it editable, he 
instantly gets an error about how Alice has locked it.  Voila, Bob 
never wastes his time on unmergeable changes.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org