On Thu, Mar 12, 2009 at 10:11:13AM +0100, Thomas Keller wrote: > > This one is dead. Without much effort, Dan convinced me that selectors were > > a better approach than options and having done that I very much agree. [...]
Yeah, I like the outcome here a lot. > Then this branch should probably be suspended. I'd like to also suggest and propose an additional convention, when using suspend certs - that is to also add a comment cert describing the reason for the suspension. > > Which is about setting/clearing execute bits based on mtn:execute. In a > > nutshell, the idea is that if mtn:execute is set to true we set the execute > > bits, if it's set to false we clear them, otherwise we leave them alone. > > This seems reasonably sensible, but means that if you update from a rev with > > mtn:execute set to true on some file to some earlier rev where that file had > > no mtn:execute attribute the execute bits will be left on rather than > > cleared. > > Do you see that as a blocker for 0.43? While the attribute handling is > still not perfect, it already got a lot better, no? Is this also the case for a forward update - ie, from a rev with an explicit setting to a rev where the attr has been dropped? If so, I'd say it could be worth more consideration - otherwise it's rare enough that it can be addressed with documentation in the meantime. I'm not convinced this is the wrong behaviour in either case (dropping the attr amounts to a "don't care" setting), but some thought about "least surprise" for user expectations is needed. The counter-argument is that "update" should produce the same result as "checkout", plus local changes, and "checkout" defaults to no-exec. So.. perhaps "diff" or "status" should show the x-bit set somehow as a workspace change carried across from the update? Could be useful in general to find files that have mismatched attrs -- Dan.
pgpyrLN8ggSaG.pgp
Description: PGP signature
_______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel