Re: [Monotone-devel] automate log?
Thomas Keller [EMAIL PROTECTED] writes: Stephen Leake schrieb: I'm thinking of adding a new 'automate log' command. It would have options for specifying what data to include in the output, and output everything in basic_io. The rationale for this is that the current Emacs DVC implementation of show log for this file is incredibly slow. Emacs DVC uses the existing automate functions to retrieve all the information it needs for show log for this file. That ends up being a _lot_ of automate calls, and it scales with the size of the database, since essentially every revision must be examined to see if it changes the file. Even using automate stdio, it is far too slow to be useful. I've implemented that as well and used automate get_content_changed and automate get_corresponding_path so I only had to examine those revisions where the file was actually changed (content marks). This is actually quite fast and can works incrementally just like mtn log does. Emacs DVC uses get_content_changed as well. However, that does not show _all_ revisions that changed the file; only the last revision that did. So we have to call it again on that revision, etc. This is too slow, at least in the Emacs implementation. It does not examine _every_ revision in the database; I just had that impression because it was so slow :). One problem with the Emacs implementation is that it finds _all_ revisions that changed the file, even if the user only requested the last 10 (emulating 'mtn log --last-n'). I'll fix that first, and see if it's fast enough. A basic_io implementation could also be incremental, although the parser has to be prepared to deal with partial stanzas in the input. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] automate log?
Stephen Leake [EMAIL PROTECTED] writes: Thomas Keller [EMAIL PROTECTED] writes: Stephen Leake schrieb: I'm thinking of adding a new 'automate log' command. It would have options for specifying what data to include in the output, and output everything in basic_io. The rationale for this is that the current Emacs DVC implementation of show log for this file is incredibly slow. Emacs DVC uses the existing automate functions to retrieve all the information it needs for show log for this file. That ends up being a _lot_ of automate calls, and it scales with the size of the database, since essentially every revision must be examined to see if it changes the file. Even using automate stdio, it is far too slow to be useful. I've implemented that as well and used automate get_content_changed and automate get_corresponding_path so I only had to examine those revisions where the file was actually changed (content marks). This is actually quite fast and can works incrementally just like mtn log does. Emacs DVC uses get_content_changed as well. However, that does not show _all_ revisions that changed the file; only the last revision that did. So we have to call it again on that revision, etc. This is too slow, at least in the Emacs implementation. It does not examine _every_ revision in the database; I just had that impression because it was so slow :). One problem with the Emacs implementation is that it finds _all_ revisions that changed the file, even if the user only requested the last 10 (emulating 'mtn log --last-n'). I'll fix that first, and see if it's fast enough. It turns out there was a nasty bug in the Emacs implementation; it was actually an infinite loop. So now it works; still slow, but acceptable given everything else on my list of things to do. So I won't be working on 'automate log' right now; maybe later. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] [best practices] How to merge a large code dump with no history?
I just received a pretty large code dump for Botan that adds a number interesting things. However all the changes are mixed together (about 10 distinct changes). And one change, that converts all bare pointers to either shared_ptr or auto_ptr, changes nearly every file. I have currently just moved a version into mtn based against the same version of Botan they used and reverted changes that definitely wouldn't go into mainline (deleting algorithms, mostly). This seems like it would be the easiest way to handle further code dumps in the future as well (I can just unzip into a workspace). But if I check this in as a new branch, how do I get singular changes out again? What is the best way to deal with a situation like this with mtn? `pluck`? A merge tool trick? 'Don't do that then'? -Jack ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [best practices] How to merge a large code dump with no history?
Jack Lloyd writes: I just received a pretty large code dump for Botan [...] I thought Botan used monotone upstream? Am I mistaken? -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [best practices] How to merge a large code dump with no history?
On Sat, 2008-05-24 at 09:33 -0400, Jack Lloyd wrote: I just received a pretty large code dump for Botan that adds a number interesting things. However all the changes are mixed together (about 10 distinct changes). And one change, that converts all bare pointers to either shared_ptr or auto_ptr, changes nearly every file. I have currently just moved a version into mtn based against the same version of Botan they used and reverted changes that definitely wouldn't go into mainline (deleting algorithms, mostly). This seems like it would be the easiest way to handle further code dumps in the future as well (I can just unzip into a workspace). But if I check this in as a new branch, how do I get singular changes out again? What is the best way to deal with a situation like this with mtn? `pluck`? A merge tool trick? 'Don't do that then'? I'd go with don't do that then (to the big dump, not the wanting to split it). But since someone *did* do that, maybe commit in a branch (which nobody should ever merge back), undo the different changes individually (lots of annoying work, but at least you have the help keeping track of where you are), and pluck each undo backwards (mtn pluck -r child -r parent). Or ask them to split it for you and re-send. :) ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [best practices] How to merge a large code dump with no history?
On Sat, May 24, 2008 at 05:57:49PM +0200, Ludovic Brenta wrote: Jack Lloyd writes: I just received a pretty large code dump for Botan [...] I thought Botan used monotone upstream? Am I mistaken? Yes. I use Montone for my VCS working on Botan and other things. But the people who sent me patches do not. I just got a .zip file of sources. [To clarify: this is a Montone usage question, not a development-of-Montone-related question] -Jack ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [best practices] How to merge a large code dump with no history?
On Sat, 2008-05-24 at 17:57 +0200, Ludovic Brenta wrote: Jack Lloyd writes: I just received a pretty large code dump for Botan [...] I thought Botan used monotone upstream? Am I mistaken? Yes, Jack Lloyd is Botan upstream. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] automate log?
Stephen Leake [EMAIL PROTECTED] writes: So I won't be working on 'automate log' right now; maybe later. However, I'd like to list the changes in the revs that mtn knows about, not just the ones the user mentioned in the changelog cert. I have newbies on my team that don't write good changelogs :(. So I will implement 'automate get_change_set revid'. That will retrieve the changeset(s) for the revision, and print them with cset.cc print_cset. Unless someone has a better name, or there is already a way to get this info. In 'mtn log', if a revision is a merge, the left and right change sets are mashed together, then printed. I think 'automate get_change_set' should print them separately; the client can display them together if it wants to. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] tests/automate_get_workspace_root broken on MinGW
tests/automate_get_workspace_root/__driver__.lua does: check(indir(foo,mtn(automate, get_workspace_root)), 0, true, false) check(qgrep(^..cwd..$, stdout)) That breaks on MinGW; the directory path has backslashes in it, which should be escaped. I couldn't find a 'quote_regexp' Lua function, nor did a quick search find one in pcre/*. Anyway this seems simpler: check(cwd .. '\n' == readfile(stdout)) Is there a reason to prefer 'qgrep' over ' == readfile()'? -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] tests/automate_get_workspace_root broken on MinGW
On Sat, 2008-05-24 at 12:51 -0400, Stephen Leake wrote: tests/automate_get_workspace_root/__driver__.lua does: check(indir(foo,mtn(automate, get_workspace_root)), 0, true, false) check(qgrep(^..cwd..$, stdout)) That breaks on MinGW; the directory path has backslashes in it, which should be escaped. I couldn't find a 'quote_regexp' Lua function, nor did a quick search find one in pcre/*. Anyway this seems simpler: check(cwd .. '\n' == readfile(stdout)) Is there a reason to prefer 'qgrep' over ' == readfile()'? For automate we generally want *exact* output, so readfile() is more correct. qgrep would be more for checking non-automate commands, which tend to have pretty formatting and human-targeted extra chatter that's OK to change. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
