On Wed, Mar 11, 2009 at 7:29 PM, Thomas Keller <m...@thomaskeller.biz> 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. > 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. 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. 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. 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. The log command now accepts a --revision option to log a specific set of revs. The new u: and m: selectors can be used with this option and allow for logging back to the point of the last update and revisions with changelog messages that match the specified glob respectively. I've been using these quite frequently since adding them and have found them to be quite useful.I added a flush to log around that time as well to at least make it feel like it was moving, but the recent cert loading changes make it go so much faster that this is no longer an issue. I'm really happy with how all of the log stuff has turned out, although I think there is still room for further improvements. 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. Cheers, Derek
_______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
