Re: [Monotone-devel] tests/automate_get_workspace_root broken on MinGW
Timothy Brownawell <[EMAIL PROTECTED]> writes:
> 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.
Ok, that's what I thought. My fix is committed.
--
-- Stephe
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: [best practices] How to merge a large code dump with no history?
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'? Have the botan checkout in one dir, the 'patched' version in another dir and run 'meld ' and move changes over piece-wise. That's the fastest method I know off. regards, Koen ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] automate log?
Stephen Leake schrieb: 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 '. That will retrieve the changeset(s) for the revision, and print them with cset.cc print_cset. Hrm... we already have automate get_manifest_of - or do you want to retrieve a changeset between two arbitrary revisions, like f.e. the one mtn diff outputs before the diff stanzas? Unless someone has a better name, or there is already a way to get this info. When I implemented content_diff without the changeset part in front I explicitely left room for some kind of "revision_diff" command which would print out this missing part, but maybe this is just a stupid name. 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. What do you think, would the plain revision format be sufficient or do you want to include further data in it? Thomas. -- GPG-Key 0x160D1092 | [EMAIL PROTECTED] | 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 ___ 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
[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] 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 '. 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
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] [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 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?
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
[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] 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
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
