Molle Bestefich wrote:
[snip]
> 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's why there's the 'svn:needs-lock' property!
If you set that property on a file, it will be read-only for *all* users
unless they get the lock on that file. Only then will they be able to
edit the file. So they can't just forget to lock such a file.
> 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.
Nothing is foolproof to a sufficiently talented fool.
> 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,
How?
> - 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:
We sure will do that.
> - 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.
AFAIK Subversion already does this.
> 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.
Ok, waaay too far here. Modifying ACL's?
> 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.
I think I have to mention something here:
- Implementing that would mean to modify the Subversion sourcecode,
because we would have to interfere with almost every command that
touches the working copy.
- TSVN is a Subversion client. And it has to work well with other
Subversion clients. If we would modify the ACL's and not Subversion,
then other Subversion clients will always throw errors because they
can't access the files anymore! They couldn't unlock files anymore.
Modifying the Subversion code is out of the question here.
- It took the whole Subversion team almost a year to implement the
locking features. I'm working here alone. I simply can't implement
something like that in the short time until 1.2 is released.
So, I know I asked for suggestions on how the UI should handle locks.
But I expected suggestions which actually could work, not dreams (and
not suggestions which would take whole companies half a year to implement).
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Sat Apr 9 19:01:10 2005