Re: [Monotone-devel] Time for a release

[Daniel Carosone]

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.

pgpPcrNgk6hoc.pgp
Description: PGP signature