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

Re: Disable Multiple Checkout for Binary Files or files with Specific Extensions

From: Jeremy Pereira <jeremyp_at_jeremyp.net>
Date: 2007-08-03 15:10:35 CEST

On 3 Aug 2007, at 08:51, Ulrich Eckhardt wrote:

> On Friday 03 August 2007 08:27, Sachin Sawant wrote:
>> Is their any way we can disable multiple checkout in Subversion for
>> Binary files or files with specific extensions.
>
> No, you can check out a working copy and then make a copy of it
> locally,
> ending up with two valid working copies.
>
>> I actually like the idea of setting up "svn-needs-lock" properties on
>> all those binary files but it seems OS X native applications ignores
>> the read-only filesystem bit.
>
> I'd say that only broken applications ignore that bit. To be
> precise, you
> can't "ignore" it, you have to actively override it, so one more
> point to
> that application being broken. File a bug report.

Just to clarify, you mean with the application vendor, *not* the
Subversion developers :-)

I couldn't believe it when I first read the parent e-mail so I did
some tests and, in at least some cases, it's sadly true.

XCode and TextEdit will both let you write to a read only file that
you own but give you a warning first

Vi will let you write a read only file that you own if you use the w!
command.

Omniplan silently writes the file and leaves the write bit set, a
major bug IMO. I think I'll check the behaviour on the latest
version and if it is the same, file a bug.

Omniplan is also an example of an application that uses bundles i.e.
a directory containing one or more files that the Finder treats as a
single file. Changing the write bit of the bundle directory doesn't
change the write bits of the files inside unless you do it using the
Finder (the chmod(2) system certainly does not check if a directory
is a bundle directory).

I suspect it is the bundle issue that the OP is trying to get
around. I think the only way around it is to manually apply the
svn:needs-lock property to the bundle directory and all sub
components, or would be if subversion would let you lock a
directory. Hmm, I wonder why the developers left directory locking
out...

>
> Uli
>
> --
> Sator Laser GmbH
> Geschäftsführer: Ronald Boers, Amtsgericht Hamburg HR B62 932
>
> **********************************************************************
> ****************
> Visit our website at <http://www.satorlaser.de/>
> **********************************************************************
> ****************
> Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den
> Adressaten bestimmt und kann vertrauliche Informationen enthalten.
> Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht
> der beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem
> Fall zu löschen und darf weder gelesen, weitergeleitet,
> veröffentlicht oder anderweitig benutzt werden.
> E-Mails können durch Dritte gelesen werden und Viren sowie
> nichtautorisierte Änderungen enthalten. Sator Laser GmbH ist für
> diese Folgen nicht verantwortlich.
>
> **********************************************************************
> ****************
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Aug 3 15:09:45 2007

This is an archived mail posted to the Subversion Users mailing list.

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