Dang. The same thing I was strating to work on. I knew I should have announced
I was working on it earlier. Oh well.
My solution had the same basic concept but a few differences I'ld like to
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.
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. The code is also
smaller and I tend to favor small solutions where possible.
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.
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.
On Wednesday 25 September 2002 03:20 pm, Brian Denny wrote:
> just cuz it seemed like a good one to get my feet wet with. :)
> - i assume that correct behavior is to set the svn:executable if
> the file is actually executable by the user running svn. is
> this correct? (as opposed to, for example, if *any* of the
> executable bits are set).
> - i created a helper method "is_executable" to determine if given
> file is executable by current user. it seems like a pretty
> general-purpose utility; but it's not currently used anywhere
> other than this one place. should (things like) this go in the
> public interface?
> - it seems like new tests should be written for this functionality,
> but i don't yet grok the existing test code well enough to be able
> to work this in. maybe in a few days. let me know if you wish to
> wait for the tests before accepting the patch.
> - there is a note in the issue tracker that this mechanism should
> defer to the mechanism described in issue 869 where applicable.
> as issue 869 has not been done, this is not addressed by the patch.
> - please critique. :)
-- Jeff Bellegarde
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Wed Sep 25 23:36:41 2002