db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michelle Caisse <Michelle.Cai...@Sun.COM>
Subject Re: Spurious executable file property in svn repository
Date Thu, 01 Sep 2005 14:35:13 GMT
Hi Michael,

Michael Bouschen wrote:

> Hi Michelle,
> thanks for the info, this is very helpful!
> I agree we should skip the svn:executable flag from the files in the 
> repository. What about the script createdb.sh from 
> tck20/test/sql/derby? I think shell scripts should be executable. 
> However, I think we do not need this script anymore, so let's remove it.

Yes, this should be removed.

> I installed the Subversion 1.2.3 Win32 binaries as you suggested and 
> it works fine. I decided to remove the subversion component from my 
> cvgwin installation instead of renaming the svn executable. I'm not 
> sure whether svn comes with dlls which also need to be renamed.

I'm sure this is the right approach.  If I really understood how to use 
that cygwin installer, I'd do it too :-)

> Would it make sense to add your findings to our SubVersion wiki page 
> http://wiki.apache.org/jdo/SubversionRepository ? I hope to get more 
> contributors and committers and they would run into the same problem 
> if they use svn from cygwin.

Good idea.  I'll do that.

Thanks for your comments.

-- Michelle

> Regards Michael
>> Hi Michelle,
>> +1
>> And thanks for running this down.
>> I don't believe that the JDO project ships anything for which the 
>> executable flag needs to be on. We use maven for executing stuff, and 
>> if maven doesn't care if the -x bit is on, we should not either.
>> So I agree that the svn:executable flag is just a distraction and we 
>> should remove it from the project. And keep from adding it in future.
>> Craig
>> On Aug 31, 2005, at 4:20 PM, Michelle Caisse wrote:
>>> Hi,
>>> There has been discussion here about the Windows subversion client 
>>> automatically assigning the executable property to non-executable 
>>> files. I believe I have a solution for this.  I also suggest that we 
>>> clean up the executable properties currently in the repository.
>>> Subversion carries executable information in the built-in property 
>>> called svn:executable.  This property, unlike others,  may be 
>>> present or absent, but it has no value.  You can add it or delete 
>>> it, but but you cannot change it.
>>> In theory, subversion ignores Windows file permissions; by default 
>>> svn:executable is not set. In fact, cygwin svn acts like Unix svn 
>>> and determines the svn:executable property based on file permissions..
>>> If you create a file via the cygwin command line,  by default it is 
>>> executable only if the filename ends with .bat, .com or .exe*, or if 
>>> its content starts with #!.  [That's what the doc says, but even in 
>>> these cases I get -x.] If you create a file via a Windows tool by 
>>> default its Windows permissions are executable by all and cygwin 
>>> interprets the Unix-style permissions this way as well.  If the file 
>>> is executable by all, cygwin svn sets the svn:executable property on 
>>> the file.
>>> (1) I suggest that we run
>>>     svn propdel -R svn:executable .
>>> from jdo to remove the svn:executable property from all of the files 
>>> in all the projects in the repository and check in the cleansed files.
>>> (2) I suggest that Windows/cygwin users who don't want to have to 
>>> think about using svn propdel or chmod use a non-cygwin version of 
>>> svn.  I installed the Subversion 1.2.3 Win32 binaries from the link 
>>> at the bottom of 
>>> http://subversion.tigris.org/project_packages.html.  It seems to 
>>> work fine.  You will have to add the svn.exe location to your 
>>> Windows PATH variable, of course.  You will also need to rename the 
>>> svn in your cygwin install to something else because when svn is 
>>> invoked from a cygwin window, the cygwin version is found even if 
>>> your cygwin/bin directory is later on the path.
>>> Alternatively, Windows users could set file permissions in Windows 
>>> Explorer. (Right-click on the top-level folder & select Properties. 
>>> Select the Security tab. Click Advanced. Remove all instances of 
>>> Read & Execute from the Permission Entries. Click "Reset permissions 
>>> on all child objects and enable propogations of inheritable 
>>> permissions". Click Apply. OK. OK.) You would have to do this again 
>>> when you do a clean checkout. Comments?
>>> -- Michelle
>> Craig Russell
>> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
>> 408 276-5638 mailto:Craig.Russell@sun.com
>> P.S. A good JDO? O, Gasp!

View raw message