2009/3/12 Thomas Keller
<address@hidden>
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 one should probably be suspended, yes.
>> nvm.changelog-editor and
>
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...
Agreed. It's pretty high on my list of things to look at so with any luck I'll get back to it in the not too distant future.
> 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
... in the same format as the revision headers printed by status and log. ;)
* have a simple mtn dropcert <revid> <certname> command which can undo a
failure
Yeah, this would essentially allow for amending certs (ok, replacing them) on revisions you have committed but not pushed a little more conveniently. My problem is that I never see the problem until *after* I've pushed something and see spelling errors in the irclogger messages.
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?
This would also be easy enough to do. Apparently there are lots of strong feelings on this as well, with regard to things like the mutt email client and its ability to edit headers or some such. I'm not sure I see what the fuss is all about though, if you want to add headers and can't then you're stuck, if you don't want to add headers but you can and choose not to then all is well.
> 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.
It's certainly a good idea to get something done, rather than have overly grand scheme's that prevent you from getting anything done. I was thinking along these lines with the first few commits to the changelog-editor branch, in terms of not touching the log output.
>> 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.
Agreed.
Cheers,
Derek