Molle Bestefich <firstname.lastname@example.org> wrote on 04/13/2005 02:43:28
> > - If you don't have the lock, the file is readonly and you can't edit
> Not true, editors are NOT guaranteed to care diddly-squat about
> read-only being set.
> Read-only is a residue from the good old DOS days, it's not guaranteed
> to mean anything to a Windows application. Windows applications are
> what TSVN has to do with.
While what you say is of course technically true, I suspect most editors
respect the property. VSS and PVCS among others have relied on this
read-only behavior for more than a decade. I have never seen editors have
a problem with it. Some even turn on their own overlays when it is set.
> > in both cases the svn:needs-lock property is set.
> So it is.
> And it's effect should be that TSVN tells the user "you need to lock
> And an overlay would be the right way to do that, seeing as that's how
> we tell the user everything else. Telling the user to switch all his
> folders to 'Detailed' view and enable an extra column in Explorer to
> show just this information is wrong.
I think your argument is that you want TSVN to check for the needs-lock
property and decorate when it is present? I can understand that
sentiment, but I liken it to wanting to know if someone else has the file
locked. That would be great to know, but at too high a cost. There is no
way that TSVN can retrieve that property on every file, and provide good
performance. The Subversion devs decided to follow the convention that
most other locking tools use, which is to use the read-only attribute as a
hint to the user and their tools that a lock should be obtained before
editing the file. I do not think there is anything else that TSVN can or
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Wed Apr 13 20:55:01 2005