SteveKing wrote:
> Nothing is foolproof to a sufficiently talented fool.
That sort of inclines that the case I proposed wasn't realistic.
I think, in fact, that the case stated is the *most* realistic to take place.
>> 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?
Oh, we just need to make sure it's a recognized keyword.
It was just so that we don't forget to add it to the 'properties' tab.
(And the helpfile.)
>> - make sure that files that are checked out with the "svn:needs-lock"
>> attribute AUTOMATICALLY has the good old read-only DOS attribute
>
> AFAIK Subversion already does this.
Ah, ok!
That would certainly be a great step towards doing locking in a good way.
>> 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?
I think so?
The SVN model with WC's and all doesn't lend itself to the scenario
it's now providing functionality for. This is the missing piece that
provides that functionality. The SVN developers might not know this
because they're all on Linux boxes, but anyway :-), hehe.
We can't know for sure right now how many applications disregard the
DOS read-only flag, which is really what this boils down to. ACLs is
a safe and hardcore (= if done right, it has the promise to Just-Work,
always) way to do it.
> 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.
Aye? I don't understand..
> - 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.
*sigh*. You're right.
It certainly makes a good point for doing this in the Subversion
libraries and not TSVN. I estimate the number of people using both
TSVN and also another tool to be very low, since TSVN is the best
there is, and you don't need anything else. Period ;-).
(CL client? What's that?)
> - 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.
Ack! That's a misunderstanding. I said "when this basic
functionality is in place". Eg. do the DOS read-only flag first, and
do this in the future.
I just wanted to raise the discussion and point to a very applicable
solution, I never said that I think it should be implemented *now*...
> 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).
See above.
(I'd be happy to lend a hand with the ACL code, but I wouldn't have a
clue how to integrate it with TSVN though.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Sat Apr 9 20:28:35 2005