Re: [Monotone-devel] git fast-export
Hi, Derek Scherger wrote: On Mon, Jan 5, 2009 at 6:52 AM, Markus Wanner mar...@bluegap.ch wrote: (I'd also love to see the underscore in cvs_import and git_export vanish. But that's another issue..) Just following up on this. What would you prefer instead (replace the underscore with dashes) or subcommands (like ls foo) of cvs and git (mtn cvs import, mtn git export, etc.) ? Please note that this is not exclusive to your patch, but involves more general redesign and cleanup of the mtn commands. In this case, yeah, IMO it would be nicer to have a sub-group of mtn cvs and mtn git commands. mtn git export mtn cvs import mtn hg pull (one fine day) mtn git pull (another fine day) Or, we decide that single commands are better and turn everything into an underscore writing. I personally don't think these look very compelling: mtn ls_branches mtn db_init The point here is UI consistency. But that certainly needs more thought and discussion. I don't really want to get into it now. Maybe on the Mini-Summit? Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: January Mini Summit (Jan 17th and 18th)
Lapo Luchini schrieb: Method of meeting… IRC, I guess? Wiki says so. (if we're too few people Skype-conference might be easier, as it leaves hands free for writing code…) But IRC could be logged and sometimes people might want to leave their desk for a short time. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] times to load various things from the database
On Sun, Jan 11, 2009 at 8:35 PM, Derek Scherger de...@echologic.com wrote: On Sun, Jan 11, 2009 at 9:04 PM, Nathaniel Smith n...@pobox.com wrote: Right, roster deltas themselves are tiny, and therefore quick to parse (they're basically like revisions). The problem in profiles has always been a combination of poor access patterns/caching, and the overhead of copying the whole large roster structure in-memory before applying the small delta. I don't think disk access patterns are affecting my test as this is on a hot cache and the database fits in ram comfortably. Looking at where database::get_roster_version applies the list of deltas during reconstruction I don't immediately *see* anywhere that is copying the roster, although I'm sure a copy could be hiding in there somewhere. I'm not talking about disk access, I'm talking about the roster cache :-). My impression is that to load N rosters in dag order we end up doing something like: - load roster 1 by loading roster N and applying N-1 deltas to it. - load roster 2 by loading roster N and applying N-2 deltas to it. - ... - load roster N. Which is O(N squared). Yes, if you're doing the O(n^2) pessimal thing, then it will suck no matter what :-). If you reconstruct in the other order, then the cache has a chance to help: - load roster N by loading it from the database - load roster N-1 by pulling roster N from the cache, copying it, and applying 1 delta to it - load roster N-2 by pulling roster N-1 from the cache, copying it, and applying 1 delta to it etc. So for the code you're running the access pattern doesn't play well with the cache, and if the access pattern or cache were better, then the copying would be the big problem, that's what I meant :-). It appears that building the reconstruction_graph to recreate a roster takes time comparable to applying the list of deltas when reconstructing the roster as well and I wonder whether we could do better using the cached revision_ancestry data? The comment in graph.cc about loading too much of the storage graph into memory doesn't seem all that relevant as we load the full ancestry cache in many other places. I doubt it. Profile first, but 1) optimizing inner parts of the algorithm (like delta application or reconstruction_graph building) is useless when the problem is that the outer code is calling them too many times. O(n^2) with one inner chunk twice as fast is still O(n^2), 2) we load the full ancestry cache in very few places these days, we've slowly implemented local algorithms for most things as loading the full graph really does become a bottleneck. -- Nathaniel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] throw usage(); or N(); for argument checking?
On Sun, 2009-01-04 at 11:14 -0800, Zack Weinberg wrote:
A command that does throw usage() gives the same result as calling
mtn help command, printing full usage info to stderr, where N()
results in mtn: misuse: message on stderr and will put a note in any
debug log.
As long as the message is maintained in case of throw usage(), I'm
fine. I dislike tools which just throw the complete usage page at me and
let me figure myself. Some hint on what's wrong certainly helps. And
that hint should survive, IMO.
So I guess we should standardize on throw usage(), but give usage a
what() and make the constructor take a message.
I'm dubious about printing the full usage message on any command line
mistake. Those are often long enough that they make the actual
diagnostic scroll off the top of the terminal or at least be visually
lost in a sea of chatter.
Hmm, plus there's the question of where to draw the line. Wrong number
of arguments (easy)? Missing required --options? Options that are only
required because of the number of arguments (like with 'mtn revert')?
Nonsensical combinations of options (--message with --message-file)?
Invalid argument types ('mtn approve not_a_revision_id')? Any
distinction would be somewhat arbitrary, and therefore
annoying/confusing...
What would be really good is if we could give customized usage advice
based on the error, e.g. currently we have
$ mtn ls
mtn: misuse: no subcommand specified for 'ls'
but 'mtn help ls' prints a 55-line message the relevant part of which
is in the *middle.* It would be great if we could extract just the
subcommands of 'mtn ls' part of that message and print it after the
above diagnostic.
zw
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
