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

RE: Disabling automatic setting of svn:executable property

From: Bob Archer <Bob.Archer_at_amsi.com>
Date: Fri, 27 May 2011 14:45:43 -0400

> > We have a lot of users using Subversion under Cygwin, which means
> that
> > any files they add get marked as executable by default (and
> almost
> > always uselessly).  Is there any way to disable the automatic
> setting
> > of the svn:executable property on an "svn add"?
> > The closest thing I see in the manual is --no-auto-props, but
> that
> > doesn't seem to have the desired effect in a quick test.
> > --
> > Daniel
>
> Is the execute property of the file on? I expect it is. Use chmod
> to turn it off before adding the file.
>
> (this is mostly an educated guess since I don't use cygwin).
>
> BOb
> The problem is that any file created by a non-Cygwin Windows
> program will show up in Cygwin as mode 777 by default, unless you
> do a chmod from the Cygwin shell afterwards. What I'm looking for
> is a solution that would be convenient for the Cygwin/Windows users
> and not subject to the "user needs to do N things before every svn
> add / whoops, user forgot step M out of N" problem.
>
> I spent a bit of effort when we did our recent cvs2svn fixing up
> inconsistent permissions in the old CVS repository. But it looks
> like pretty soon we'll have a similar situation in the Subversion
> repository unless we can find a good way to prevent execute bits
> from being accidentally set. I'd hate to have to set up a
> draconian pre-commit hook that rejects commits setting non-
> program/script files to executable. And I would find it hard to
> believe we're the first to have this issue.
> --
> Daniel
>

Is there a reason you don't use a windows native svn.exe binary?

You could create an alias in cygwin for the user which does the chmod before an svn add.

BOb
Received on 2011-05-27 20:46:19 CEST

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.