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

Re: [TSVN] how should the UI look like

From: Molle Bestefich <molle.bestefich_at_gmail.com>
Date: 2005-04-09 22:35:50 CEST

>>> Ok, waaay too far here. Modifying ACL's?
>>
>> Actually, I think that both ACLs and the DOS read-only flag are
wrong for this.
>>
>> ACLs just happen to be there and support this kind of functionality,
>> and the DOS flag just happens to still be around, but is in no way
>> guaranteed to actually work.
>>
>> Ergo, we should hook the filesystem API's entry points.
>>
>> When a write to a non-locked, "needs-lock" file is attempted, present
>> the user with a dialog: "You need to lock this file before starting
>> work on it", and then return ACCESS DENIED to the application
>> afterwards.
>
> Subversion set's the read only flag. Subversion handles this.
> TortoiseSVN is a Subversion client. So we can't change that.

Except for the fact that we'd be screwing up the non-existing
simultaneously running other Subversion applications, I can't see why
not :-).

That said, it _would_ make it a much prettier solution if there was
something defined in the Subversion libraries. It's meaning should be
something like, "I'm a Subversion-library based application, allow me
to modify these files even though they're unlocked+needs-lock".

Not sure how to implement it. I'm thinking that the SVN library
should have a place where the 'deny-unlocked-file-modifications'
daemon could register itself. By doing this it tells the SVN library
to do all of it's file modification actions through this daemon
instead of through the filesystem API that we've hooked and may abort
on. The daemon itself would of course in the end also be invoked by
these calls, but it can recognize it's own PID and let the call
through, or something like that :-).

> I just want suggestions on how to implement the locking
> features Subversion provides with its 1.2 release. That's what I have to
> do *now*. So your suggestions may be good for the future, but right now,
> they just lead this whole discussion to where it doesn't help me now at all.

I apologize for the noise! I haven't been here so long and I wasn't
aware that stuff had already been discussed and implemented and to
what extents.
I'll just grab a big cup of shut the f*** up.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Sat Apr 9 22:36:12 2005

This is an archived mail posted to the TortoiseSVN Dev mailing list.

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