I'm moving a discussion from the bug tracker (http://bugs.darcs.net/ issue538) to darcs-users:
Op 25-apr-2008, om 13:05 heeft Eric Kow het volgende geschreven: > >> Hell, the existing --set-scripts-executable switch as used by >> apply is >> already a hack -- you might as well rip that out and replace it with >> the aforementioned utility. > > Right, that's what I meant. --set-scripts-executable is a hack indeed. I made a simple fix for the darcs-1 repository case, but - again - how to scale it to hashed repositories wasn't obvious. In a darcs-1 repository, I can store the test script in the pristine tree with the executable bit set and all is well. But in a hashed repo, the pristine tree isn't stored as a directory in the filesystem, and the format of the pristine in hashed repos seems not to specify whether a file is executable or not. So I would either have to extend the hashed pristine format to include executability, or to change the semantics of --set-scripts-executable on darcs-1 repos, or just accept different behavior of --set-scripts- executable on different repo formats. I suspect that this difference in semantics also shows with darcs get: if you darcs get a darcs-1 repo with --set-scripts-executable, your test script should work; if you get a hashed repo, it won't. If you know more about the intended semantics of darcs than I do: what option should I choose here? Are there any compelling reasons for keeping --set-scripts-executable as a darcs flag instead of an external tool? BTW, how do other VCSs handle executability (it seems that svn stores executability in the pristine)? Regards, Reinier PS: twb: Maybe an even simpler workaround would be to use 'sh mytest.sh' as the test command instead of './mytest.sh'. _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
