Re: [Monotone-devel] Time for a release

[Thomas Keller]

Derek Scherger schrieb:
> On Wed, Mar 11, 2009 at 7:29 PM, Thomas Keller <address@hidden> wrote:
> 
>> 6) Derek, whats up with nvm.experiment.binary-roster-deltas,
>>
> 
> This was purely an experiment. I was hoping that it would speed up roster
> loading but it didn't make any measurable difference so I think it's a dead
> end. The binary format was possibly a bit nicer than the associated basic_io
> format that it replaced in terms of the printing and parsing code. If we
> ever do move away from basic_io to length prefixed binary data this could be
> an example of one approach.

Ok, then this is stalled. Should we suspend these and similar branches?

>> nvm.changelog-editor and
> 
> 
> I'm still hoping to do something with this, but I'm not in any rush and I
> don't think this should hold up the release. Possibly the thing to do is to
> move more of this into lua hooks so it is configurable. I would very much
> like to unify the output from 'mtn status' and 'mtn log' so that we have one
> pretty printed form of revisions used by both commands. If this format can
> be worked into the commit command as well then all the better.

No rush on this one, either. I just have the slight feeling that
ambitious (working) experiments in the past tend to die a slow death
because they're forgotten after some time. I speak for myself here as
well, having a lot of unfinished work laying around from 2008 or even
2007...

> I have wished I had editable branch names during commits on numerous
> occasions so I would like to get some agreement on this. At least a couple
> of people have wondered about a lua hook or something to enable/disable this
> feature which can be done but I'm a bit skeptical on whether this is really
> necessary or not.

I think the main problem here is that it is so hard to recover from
failures. A possible solution to this dilemma w/o any additional lua foo
could also be:

* print all issued certs directly after a commit
* have a simple mtn dropcert <revid> <certname> command which can undo a
failure

If this is in place I'd even vote for expanding the functionality to
allow multiple new certs, just like it is possible to add email headers.
I.e. why not adding multiple author certs on a revision which origins
from a patch by adding new "author: " lines?

> To unify output from status and log we need to settle on one of the two
> different output formats. Status currently prints one line per path, with a
> single word prefix indicating what changed while log currently prints a more
> abbreviated summary which is very much influenced by the internal structure
> of a cset. I prefer the output from status over that of log so that's the
> direction I would move in if there are no objections. It will be a few
> weeks  before I get back to this line of changes though.

I agree that this is wanted, but I could actually see this happen
sometime later, this is not directly related to the changelog edit
functionality.

>> nvm.experiment.log-options? Should any of those
> 
> 
> 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. [...]

Then this branch should probably be suspended.

> The one thing I would like to get sorted out before a release is the issue
> described here:
> http://thread.gmane.org/gmane.comp.version-control.monotone.devel/16118
> 
> 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?

Thomas.

-- 
GPG-Key 0x160D1092 | address@hidden | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en

signature.asc
Description: OpenPGP digital signature