* Working on a C++ codebase that runs on Windows and Linux
* Desire to store Linux-specific files (vendor exes) with the source tree
* When code is updated/checked out on Windows (using Cygwin bzr) the +x bit is lost. Suggested workaround of using bzr revert is ineffective for me.
* Probably relevant: In Cygwin /etc/fstab, the drive is mounted with 'noacl' option to prevent Cygwin from mucking up Windows file permissions.
Agreed the root cause of this problem is the terrible way that recent versions of Cygwin handle file permissions. File permission handling in Cygwin has been poor ever since the 'nontsec' option was removed.
Agreed that one solution to this problem is not to use the Cygwin version of bzr.
For my use case, a per-user configuration option to ignore and preserve the +x bit would be ideal. In other words an option I can set on Cygwin side only that causes bzr not to see the +x bit at all, but that doesn't lose any +x on the file that may have been set in the Linux environment.
My use case:
* Working on a C++ codebase that runs on Windows and Linux
* Desire to store Linux-specific files (vendor exes) with the source tree
* When code is updated/checked out on Windows (using Cygwin bzr) the +x bit is lost. Suggested workaround of using bzr revert is ineffective for me.
* Probably relevant: In Cygwin /etc/fstab, the drive is mounted with 'noacl' option to prevent Cygwin from mucking up Windows file permissions.
Agreed the root cause of this problem is the terrible way that recent versions of Cygwin handle file permissions. File permission handling in Cygwin has been poor ever since the 'nontsec' option was removed.
Agreed that one solution to this problem is not to use the Cygwin version of bzr.
For my use case, a per-user configuration option to ignore and preserve the +x bit would be ideal. In other words an option I can set on Cygwin side only that causes bzr not to see the +x bit at all, but that doesn't lose any +x on the file that may have been set in the Linux environment.