On Sat, Feb 28, 2009 at 2:51 AM, Felipe Contreras
<address@hidden> wrote:
> Felipe discovered what I believe to be the cause of this a few months ago
> [1]. As I understand the issue, there is no `mtn update` hook for unsetting
> execute bits, so unsetting that attribute doesn't have any effect. However,
> when doing an update that would involve moving very far through history
> (say, from the revision Felipe mentions in that email to
> h:im.pidgin.pidgin), I believe Monotone optimizes that operation to 'check
> out the new manifest [and apply working changes]', and as the mtn:exec
> property isn't set on the files in the target revision, the file's exec bit
> is unset.
So there's no fix and no clear path on how this will get fixed, right?
I've committed a fix on net.venge.monotone for this problem in b1cec3176fd56af29275c2b620f8766b4382eec8 which fixes two associated xfailed tests in the monotone testsuite (tests/attr_mtn_execute and tests/defecting_attriibutes).
It would be good to get some eyes on this change from people who understand the monotone internals. For those people, this change mainly affects the update and pluck commands and the stuff I'm marginally worried about is the make_revision_for_workspace and resolve_merge_conflicts calls because the "merged" roster may have some dormant attributes on it that previously were not there. From what I can tell, a cset between a roster with no "foo" attr and one with a dormant "foo" attr is empty but if it wasn't this change might cause some problems.
Cheers,
Derek