> So please, think of how the UI should handle this situation and make
> suggestions.
Okay. If not proper thought out, I think what people are going to use
locking in TSVN for is to forcefully disable other people's forgotten
locks. That's it.
The reasoning?
It doesn't fit naturally in anybody's workflow. In other versioning
systems you are prohibited from editing files unless you have locked
it, thus putting locking naturally in the 'flow. Not so in
Subversion. The only reason for Joe User to take a lock on a file
before he starts editing it is if he understands how Subversion works.
That might be OK for small and open source projects where most of the
developers have made a conscious, agreed choice to use Subversion and
know the technical merits and pitfalls of it.
But for Joe User, the reason to click that 'Lock' button is that the
IT department has told him that they have chosen a versioning system
called "SubVersion", and that this particular system requires him to
make sure that the system doesn't allow other users to edit a file
he's editing.
He's gonna do it the first three or 10 or 15 times. But after that,
he'll start forgetting it. The system doesn't care, it basically
works just as well without, so why would he remember? Until the day
that he cannot check in his 3D graphic or large-scale CAD/CAM project,
because someone else has been working on the binary files also.
That day, he's not going to blame himself for not getting to know the
intimacies of the versioning system better than he did. He is gonna
blame Subversion for not supporting a fool-proof workflow.
In my opinion, the things WE can do are (reverse order of importance):
- make the "svn:needs-lock" visible in the GUI and, more importantly,
- make the "svn:needs-lock" visible in the docs, so the server admin
knows he needs to add a post-commit hook that applies the attribute to
all user-editable binary file types, eg. images, 3D models and what
not. And most importantly:
- make sure that files that are checked out with the "svn:needs-lock"
attribute AUTOMATICALLY has the good old read-only DOS attribute
applied. Lots of applications honour this; it's a simple way to
ensure that the "svn:needs-lock" attribute is enforced. And don't be
confused about this: It's US that needs to make sure that it's
enforced. I think this should be considered a PRIMARY objective for
TSVN.
When this basic functionality is in place, we should go even further
with our primary objective (enforcing the needs-lock attribute).
Since TSVN is 2000/XP only, and 90% of TSVN users are thus using NTFS,
we should accomplish this goal by modifying the ACLs on checked-out
files.
What we need to do is, for each file that are checked out and has the
"svn:needs-lock" attribute:
- Go through the list of ACL entries that the item inherited automatically
- For each inherited ACL entry, add a new ACL entry for that
particular group or user, with "Deny" set for the "Write" privilege.
This will supplement the DOS read-only flag with modern ACL-based
access control and make sure that users cannot edit files that they
need to lock first, even if their applications don't care. If they
try anyway, they're going to be presented with a "Access Denied"
message, which luckily happens to fit the actual problem (s)he's
having quite well.
I don't need to mention that the added deny-write ACLs must be removed
when files are locked by the user himself.
Also don't need to add that Working Copys are personal, and *very*
much so now that locking is being introduced.
/My .2€
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Sat Apr 9 18:31:18 2005