> I put the code into 'svn_wc_add' in 'adm_ops.c'. I believe this does the work
> when the 'svn add' command is given which would allow the user to change
> 'svn:executable' before commiting. If it's done at commit time the user will
> have to make another change to fix it.
oh yeah, i hadn't thought of that one. i think it sounds good.
but does this take care of the import case?
i'd thought of this use case, forgot to ask about it, but personally lean
against it:
- add and commit a file, not executable.
chmod the file in the working copy to be
executable. commit.
should this set svn:executable?
another possible use case is:
- you have a file already under svn control, not executable
% svn propset svn:exectuable "" foo.sh
now is foo.txt being exectuable in wc
(without having to chmod it also)?
this makes sense to me, because if you do a commit and an update,
it will be executable. but OTOH maybe it's too weird for an svn propset
to be tweaking your wc.
> I'm not sure it's worthwile to check the actual user running svn. Generally
> the same command on the same file should behave the same regardless of who
> ran the command. If a file is marked as user executable it should be
> considered user executable regardless of the user involved.
why? if a file is marked as user executable, that doesn't mean it's
exectuable by the user involved... idunno -- when i check out a
file with svn:executable set, i get all the executable bits set (not
sure if/how this interacts with umask). so there's some asymmetry
anyway. i have no strong opinion on this.
> Last I checked Windows considered *.com, *.exe, and *.bat to be executable and
> everything else as data. It's been a few years since I cared so I could be
> completely wrong by now. Any windows executable is unlikely to work on any
> unix and vice versa. We may be better off making all files added on Windows
> data and only checking on Unix.
a couple people have said this now; it sounds like a nice easy solution
to me. :)
> I'm still looking at the testing situation. I think I see how to do it now.
> I'll try to get something to Brian if I can figure it out.
cool. :)
:) brian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Sep 26 01:18:14 2002