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

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

From: Robert Hunter <robert.hunter_at_gen-i.co.nz>
Date: 2004-11-17 07:10:34 CET

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

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

(I'm sure this has come up before, but it sounds like a doable solution
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
Received on Wed Nov 17 07:11:21 2004

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.