Re: [Monotone-devel] nvm.experiment.pcre ready for merge
On 10/5/07, Richard Levitte [EMAIL PROTECTED] wrote: zackw All tests pass, 'make distcheck' is in zackw progress. For the record: I'm not sure whether 'make distcheck' succeeds, because the 'suspend' test failed - it does this about 75% of the time for me :-( Personally, I've no problems with having the PCRE stuff join mainline, especially since it (as I understand it) will greatly reduce the pain of having to deal with boost. Right, indeed that is the whole point. A question: how much does the PCRE syntax differ from the boost::regex syntax? Is that relevant to know? Will it impact much on users, for example when dealing with .mtn-ignore? I believe the PCRE syntax is a superset of the boost::regex syntax, since the latter was based on an older version of Perl regexes. (The differences mostly affect people doing Very Clever Things with regexes, that probably no one will do in an ignore file. One hopes.) zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] missing public keys
Le vendredi 05 octobre 2007 à 14:08 -0700, Nathaniel Smith a écrit : On Fri, Oct 05, 2007 at 10:07:49AM +0200, Benot Dejean wrote: Let me explain better. I'm missing two public keys: - an old key of mine that i used to commit on this project. - a key from a another developer. I though the keys were stored in the database. My old key was surely in my ~/.monotone/keys but i think i deleted it because i no longer needed it. Maybe that was a mistake. But the developer key, i never touched it: i got this developer's revisions only by sync'ing. I don't understand. These branches are 1 year old. I don't understand either; for every cert in a db, we're supposed to also have the corresponding public key in the db. Is there a way to fix the db then ? Like re-signing the certs ? Is it possible that a schema migration once missed some keys ? What does ls keys say? It doesn't show the missing key. They are not in the db, neither in the keystore. Does the server (that you and the other developer presumably sync with) have the keys? No server. The project is dead and i haven't managed the developer. In order to be able to checkout, i've patched bogus_cert_p to ignore unknown cert. Thank you very much. -- Benoît Dejean GNOME http://www.gnomefr.org/ LibGTop http://directory.fsf.org/libgtop.html signature.asc Description: Ceci est une partie de message numériquement signée ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] database or disk is full
Le vendredi 05 octobre 2007 à 13:15 -0700, Zack Weinberg a écrit :
On 10/5/07, Benoît Dejean [EMAIL PROTECTED] wrote:
I'm afraid this is a known bug. No one has yet been able to track it
down. Does this happen 100% reproducibly for you? Does it go away if
you rebuild the mtn executable with CFLAGS='-g -O0' CXXFLAGS='-g -O0'?
Yep, it does not happen with -O0
Ok, next request - please rebuild the executable at -O2, *except*
sqlite/pager.c, which compile at -O0. The simplest way to do that is:
make clean
make mtn
^C the link
rm lib3rdparty.a
mv sqlite/lib3rdparty_a-pager.o{,.bad}
make mtn CFLAGS='-g -O0' CXXFLAGS='-g -O0'
(This doesn't work so i've copied make output, edited it and run it with
Ox).
And see if that works. If it does work, please also try it with that
one file compiled at -O1. If it does *not* work, please cycle through
the rest of the sqlite/ directory and see if you can find a single
file that when compiled at -O0 (with the rest of the files compiled at
-O2) makes the problem go away.
pager.c is the right file.
The problem disappears in O0 and O1, db init and pull work again.
(If you'd rather not do all this work yourself, but don't mind giving
me an ssh-accessible account on your computer, please email me
off-list.)
So far i can do it, but you think this is a ppc-specific issue, no problem.
--
Benoît Dejean
GNOME http://www.gnomefr.org/
LibGTop http://directory.fsf.org/libgtop.html
signature.asc
Description: Ceci est une partie de message numériquement signée
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] [PATCH] parent selector 'p:xxx'
This afternoon I finally got really nerved having to type
$ mtn diff -r `mtn automate parent rev` -r rev
or the rather ugly, unhandy and partly unrecognizeable
$ mtn log --diffs --no-graph --brief --from rev --to rev
just to get the diff output which has lead to a particular revision
rev (which in turn I usually figure out via mtn annotate
beforehand).
I don't know whether it is just me, but I rather often need the _parent_
of a revision (if more parents exists, I'm out of luck doing an easy
diff anyway) and especially -- even if a command can figure it out --
want to avoid even having to copy paste it more revision ids than
necessary.
So, find appended a small patch against h:n.v.m which implements a
p:rev selector. With this I now can finally use short commands like:
$ mtn diff -r p:rev -r rev
The rev here can be an appreviated revision, too.
In case others find this additional selector also handy, are there any
objections if I commit this to n.v.m? Else I will include this stuff
just into the patchset I maintain for OpenPKG's monotone package...
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
Index: selectors.hh
--- selectors.hha580067010375b01e72094ebc255e26da4894384
+++ selectors.hh04a1e8390e95624c89c100fd14de9157f5309dc1
@@ -30,6 +30,7 @@ namespace selectors
sel_cert,
sel_earlier,
sel_later,
+ sel_parent,
sel_unknown
}
selector_type;
Index: selectors.cc
--- selectors.cc87df1393159bdc637059d9dfa9dfc52d50236326
+++ selectors.cc1f5468137482871fb0c6b418357caa93eed01201
@@ -79,6 +79,9 @@ namespace selectors
case 'e':
type = sel_earlier;
break;
+ case 'p':
+type = sel_parent;
+break;
default:
W(F(unknown selector type: %c) % sel[0]);
break;
Index: database.cc
--- database.cc 4ae4c79a2a7fba4f39b072de6edc52625e1f69c0
+++ database.cc b37f89c9d264b674728fda144360e30d5d3b6397
@@ -2874,6 +2874,7 @@ static void selector_to_certname(selecto
case selectors::sel_ident:
case selectors::sel_cert:
case selectors::sel_unknown:
+case selectors::sel_parent:
I(false); // don't do this.
break;
}
@@ -2914,6 +2915,11 @@ void database::complete(selector_type ty
lim.sql_cmd += SELECT id FROM revision_certs WHERE id GLOB ?;
lim % text(i-second + *);
}
+ else if (i-first == selectors::sel_parent)
+{
+ lim.sql_cmd += SELECT parent AS id FROM revision_ancestry WHERE
child GLOB ?;
+ lim % text(i-second + *);
+}
else if (i-first == selectors::sel_cert)
{
if (i-second.length() 0)
@@ -3033,7 +3039,7 @@ void database::complete(selector_type ty
// will complete either some idents, or cert values, or unknown
// which generally means author, tag or branch
- if (ty == selectors::sel_ident)
+ if (ty == selectors::sel_ident || ty == selectors::sel_parent)
{
lim.sql_cmd = SELECT id FROM + lim.sql_cmd;
}
Index: monotone.texi
--- monotone.texi 11dbcb7685ca2369e9131eb7a4c2194f6b5619ae
+++ monotone.texi cb9220003751300efd0953226bac5db97cddbbf6
@@ -2765,6 +2765,10 @@ @heading Selectors in detail
@item Identifier selection
Uses selector type @code{i}. For example, @code{i:0f3a} matches
revision IDs which begin with @code{0f3a}.
[EMAIL PROTECTED] Parent selection
+Uses selector type @code{p}. For example, @code{p:0f3a} matches the
+revision IDs which are the parent of the revision ID which begins with
[EMAIL PROTECTED]
@item Tag selection
Uses selector type @code{t}. For example, @code{t:monotone-0.11} matches
@code{tag} certs where the cert value begins with @code{monotone-0.11}.
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] database or disk is full
On 10/6/07, Benoît Dejean [EMAIL PROTECTED] wrote: And see if that works. If it does work, please also try it with that one file compiled at -O1. If it does *not* work, please cycle through the rest of the sqlite/ directory and see if you can find a single file that when compiled at -O0 (with the rest of the files compiled at -O2) makes the problem go away. pager.c is the right file. The problem disappears in O0 and O1, db init and pull work again. This is good to know. Unfortunately, it starts to smell like a compiler bug, but we'll see. (If you'd rather not do all this work yourself, but don't mind giving me an ssh-accessible account on your computer, please email me off-list.) So far i can do it, but you think this is a ppc-specific issue, no problem. Well, I'm about to ask you for even more elaborate debugging tricks. Just let me know when it gets too tedious to continue. First, please recompile sqlite/pager.c with CFLAGS='-O1 -save-temps' (do *not* include -g this time). This will drop a file named pager.s somewhere - probably the current working directory. Rename it pager.s.O1. Repeat the recompile with CFLAGS='-O2 -save-temps'; rename pager.s to pager.s.O2. Email me (off-list) both pager.s.O1 and pager.s.O2. Second, please rebuild the monotone executable with pager.c compiled at -g -O2. Run 'mtn db init' under gdb. Set a breakpoint at pager.c:3326. Run to that breakpoint.Set a watchpoint on ((struct unixFile *)pPager-jfd)-offset. Continue; every time the watchpoint triggers, continue again. Tell me all of the places where the watchpoint triggered from then until the program fails. Thanks again, zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [PATCH] parent selector 'p:xxx'
On Sat, Oct 06, 2007 at 07:09:03PM +0200, Ralf S. Engelschall wrote: So, find appended a small patch against h:n.v.m which implements a p:rev selector. With this I now can finally use short commands like: $ mtn diff -r p:rev -r rev The rev here can be an appreviated revision, too. The patch contains no tests, though otherwise looks reasonable enough. What happens if rev is a root revision? Show me stuff about revision blah seems like a pretty fundamental command -- stuff presumably including some metadata summary like log gives you, and also a diff or so. Does anyone have a good idea for what this command would be called? It would be pretty easy to add, and might solve your particular problem in a nicer way. (Also the commit notification problem that Matthew was fighting with, etc.) -- Nathaniel -- Eternity is very long, especially towards the end. -- Woody Allen ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [PATCH] parent selector 'p:xxx'
Nathaniel Smith spake unto us the following wisdom:
Show me stuff about revision blah seems like a pretty fundamental
command -- stuff presumably including some metadata summary like log
gives you, and also a diff or so. Does anyone have a good idea for
what this command would be called? It would be pretty easy to add,
and might solve your particular problem in a nicer way. (Also the
commit notification problem that Matthew was fighting with, etc.)
I know that I personally use 'mtn log --from rev --last 1 --no-graph
--diffs' *all* the time; a simple command which does this ('mtn
summarize' or the like) would be a boon, particularly if it could take
multiple revisions and output them in order.
Of course, there is really no reason this can't be handled as a shell
alias or simple script, either...
Ethan
--
The laws that forbid the carrying of arms are laws [that have no remedy
for evils]. They disarm only those who are neither inclined nor
determined to commit crimes.
-- Cesare Beccaria, On Crimes and Punishments, 1764
signature.asc
Description: Digital signature
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [PATCH] parent selector 'p:xxx'
On Sat, Oct 06, 2007 at 04:22:44PM -0400, Ethan Blanton wrote:
I know that I personally use 'mtn log --from rev --last 1 --no-graph
--diffs' *all* the time; a simple command which does this ('mtn
summarize' or the like) would be a boon, particularly if it could take
multiple revisions and output them in order.
Yeah, that's the point.
Of course, there is really no reason this can't be handled as a shell
alias or simple script, either...
Except that making users write their own code to fix our bugs is
stupid :-).
'summarize' still seems too long to type conveniently. Would 'show'
be too generic?
-- Nathaniel
--
Details are all that matters; God dwells there, and you never get to
see Him if you don't struggle to get them right. -- Stephen Jay Gould
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [PATCH] parent selector 'p:xxx'
On Sat, Oct 06, 2007, Nathaniel Smith wrote: On Sat, Oct 06, 2007 at 07:09:03PM +0200, Ralf S. Engelschall wrote: So, find appended a small patch against h:n.v.m which implements a p:rev selector. With this I now can finally use short commands like: $ mtn diff -r p:rev -r rev The rev here can be an appreviated revision, too. The patch contains no tests, though otherwise looks reasonable enough. Ok, I'll add some tests. What happens if rev is a root revision? Nothing spectacular: the selector just returns no revisions at all. This situation is already gracefully handled by the code around my patched lines. Show me stuff about revision blah seems like a pretty fundamental command -- stuff presumably including some metadata summary like log gives you, and also a diff or so. Does anyone have a good idea for what this command would be called? It would be pretty easy to add, and might solve your particular problem in a nicer way. (Also the commit notification problem that Matthew was fighting with, etc.) Yes, such a command is such good that I recently even tried to implement it in Lua with the help of mtn_automate() -- I just failed because of a bug in mtn_automate() which I reported recently, too. The name for the command would be mtn changeset or in short mtn cs. The output I expect is actually is more or less really the same as what mtn log --diffs --no-graph --from rev --to rev currently gives us: a summary information about a changeset. So, I personally would prefer that we both provide the generic selector p:rev (as it can be useful for others commands beside mtn diff, too) and also implement a mtn cs rev command which produces the output of mtn log --diffs --no-graph --from rev --to rev plus perhaps even more if available. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [PATCH] parent selector 'p:xxx'
Ralf S. Engelschall spake unto us the following wisdom: Yes, such a command is such good that I recently even tried to implement it in Lua with the help of mtn_automate() -- I just failed because of a bug in mtn_automate() which I reported recently, too. The name for the command would be mtn changeset or in short mtn cs. The output I expect is actually is more or less really the same as what mtn log --diffs --no-graph --from rev --to rev currently gives us: a summary information about a changeset. So, I personally would prefer that we both provide the generic selector p:rev (as it can be useful for others commands beside mtn diff, too) and also implement a mtn cs rev command which produces the output of mtn log --diffs --no-graph --from rev --to rev plus perhaps even more if available. I also believe that the p: selector is useful in its own right -- I find myself using `mtn automate parents` from time to time. Ethan -- The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, On Crimes and Punishments, 1764 signature.asc Description: Digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [PATCH] parent selector 'p:xxx'
On Sat, Oct 06, 2007 at 06:02:05PM -0400, Ethan Blanton wrote: Nathaniel Smith spake unto us the following wisdom: 'summarize' still seems too long to type conveniently. Would 'show' be too generic? I don't think it's too generic, necessarily, as I think one normally associates generic commands with operations on revisions, but it sort of seems funny in the presence of show_conflicts. I thought of 'view', but that's not so much a command to be performed as an action to be taken by the user, which might be a metaphor shear. show_conflicts should probably become something else in the long run anyway (merge --preview or something?), so that doesn't bother me, and I do like 'show' better than 'view'. Maybe we should just go with that. Anyone want to implement it? Should probably have almost no code of its own, just share code with log (which might need a touch of refactoring first to make that easy). -- Nathaniel -- Of course, the entire effort is to put oneself Outside the ordinary range Of what are called statistics. -- Stephan Spender ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] missing public keys
I believe I have something that can help you. I wrote a lua program that: Looks for revisions with 'bad' certificates (as reported by mtn au certs rev) which have private keys available to monotone (ie mtn au keys has a private_location), and Uses the mtn db execute command to delete the bad certs (all certs for that revision by that key because figuring out the hash of the bad certs was beyond me, however it does track all the good certs as well as bad for reinsertion), and finally, Uses mtn au cert rev to add the certs back to the database. (I managed to lose the password to my key so I had to delete the key, and generate a new one, causing monotone to complain loud and long for every invocation) I've used it on my own database and it seems to do the job without wrecking anything but I would (and did) make backups before trying it out. Assuming that no one reading this sees holes in its logic (or points out some mtn invocation that I missed that magically does this for you) I can mail you a copy. :) On 6 Oct 2007, at 8:45 am, Benoît Dejean wrote: Le vendredi 05 octobre 2007 à 14:08 -0700, Nathaniel Smith a écrit : On Fri, Oct 05, 2007 at 10:07:49AM +0200, Benot Dejean wrote: Let me explain better. I'm missing two public keys: - an old key of mine that i used to commit on this project. - a key from a another developer. I though the keys were stored in the database. My old key was surely in my ~/.monotone/keys but i think i deleted it because i no longer needed it. Maybe that was a mistake. But the developer key, i never touched it: i got this developer's revisions only by sync'ing. I don't understand. These branches are 1 year old. I don't understand either; for every cert in a db, we're supposed to also have the corresponding public key in the db. Is there a way to fix the db then ? Like re-signing the certs ? Is it possible that a schema migration once missed some keys ? What does ls keys say? It doesn't show the missing key. They are not in the db, neither in the keystore. Does the server (that you and the other developer presumably sync with) have the keys? No server. The project is dead and i haven't managed the developer. In order to be able to checkout, i've patched bogus_cert_p to ignore unknown cert. Thank you very much. -- Benoît Dejean GNOME http://www.gnomefr.org/ LibGTop http://directory.fsf.org/libgtop.html -- This email has been verified as Virus free Virus Protection and more av= ailable at http://www.plus.net ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [PATCH] parent selector 'p:xxx'
Nathaniel Smith wrote: 'summarize' still seems too long to type conveniently. Would 'show' be too generic? I think graydon once talked of a review command that would do something like this for the specified revs. On another note, I've been running a little shell script lately (coincidentally called review) that does mtn log --next 1000 --no-graph --no-merges --diffs | diffc-0.3 | less -r which shows me what I'm going to get *before* I do an update and lets me look over incoming revs. I'd be happy to call this something else though (incoming perhaps) if we use review to mean review these revs ... Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] missing public keys
On Sun, Oct 07, 2007 at 04:31:01AM +0100, Peter Stirling wrote: I wrote a lua program that: Looks for revisions with 'bad' certificates (as reported by mtn au certs rev) which have private keys available to monotone (ie mtn au keys has a private_location), and Uses the mtn db execute command to delete the bad certs (all certs for that revision by that key because figuring out the hash of the bad certs was beyond me, however it does track all the good certs as well as bad for reinsertion), and finally, Uses mtn au cert rev to add the certs back to the database. If you wanted to be careful you might insert the new certs first, so in case the thing crashes for some reason then you end up with duplicate certs (recoverable) instead of no certs (not so much). But the idea seems right otherwise. -- Nathaniel -- Eternity is very long, especially towards the end. -- Woody Allen ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
