Re: [Monotone-devel] Re: colored diffs [Was: [PATCH] parent selector 'p:xxx']
Lapo Luchini wrote: > Does anyone object if I implement that? ;-) Not me. I'd use it all the time. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Further update to notification script
In message <[EMAIL PROTECTED]> on Mon, 8 Oct 2007 10:36:32 +0100, Matthew Sackman <[EMAIL PROTECTED]> said: matthew> On Mon, Oct 08, 2007 at 02:10:28AM -0700, Nathaniel Smith wrote: matthew> > Seems like you should just get commit access to me... Who's matthew> > in charge of adding people to the server these days? Richard? matthew> matthew> I did used to have commit access - I definately sent my matthew> pubkey to Richard a while back. But then after the servers matthew> changed I think my write access was removed/lost, which is matthew> fair enough as I hadn't done any work for some time... Uhmmm, I can't have added it before the server change, because I didn't have that kind of access. Thing is, I can't see any public key with your name in the database that I have, so it's likely that you were never added by me. Please send me your public key and I'll add it. Cheers, Richard - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ "When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up." -- C.S. Lewis ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Further update to notification script
In message <[EMAIL PROTECTED]> on Mon, 8 Oct 2007 02:10:28 -0700, Nathaniel Smith <[EMAIL PROTECTED]> said: njs> Seems like you should just get commit access to me... Who's in njs> charge of adding people to the server these days? Richard? Until I apply some policy stuff, yes. Cheers, Richard - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ "When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up." -- C.S. Lewis ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: colored diffs [Was: [PATCH] parent selector 'p:xxx']
Zack Weinberg spake unto us the following wisdom: > On 10/8/07, Ethan Blanton <[EMAIL PROTECTED]> wrote: > > > It's a good idea but you need to be careful how you implement it. > > > Hardwiring VT220 color control codes would be bad. So would making us > > > depend on ncurses. > > > > ncurses is far less odious than boost -- most systems actually *have* > > ncurses, and it doesn't kick compilation times into the stratosphere, > > either. ;-) > > Well, probably it wouldn't be much trouble, but I must point out that > GNU ls manages to have optional colorized output without depending on > ncurses (however, I have no idea how that feature works). GNU ls hardwires VT220 color codes, and there is a list of acceptable TERM names for which it is used. I think it consults COLORTERM as well, but I'm not sure -- I'd have to check the documentation. > > > I'd suggest a set of Lua hooks that know the necessary escape > > > sequences for the most common TERM= settings (xterm, etc) and can > > > query the 'tput' utility for less common ones. You could also use > > > this to get at the line-drawing characters for > > > asciik... > > > > Down this path lies madness. You're reinventing terminfo. > > Not so - it's just a more arms-length version of the code we would > write if we used ncurses directly. The tput part is -- which is slow, but correct. The other part is the reinventing terminfo bit. ;-) It also makes the assumption that TERM=foo means the same thing in every location, which it may or may not. I guess I really don't see ncurses as a problem, but maybe I'm too old-fashioned. ;-) 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] Re: colored diffs [Was: [PATCH] parent selector 'p:xxx']
On 10/8/07, Nathaniel Smith <[EMAIL PROTECTED]> wrote: > > I'd suggest a set of Lua hooks that know the necessary escape > > sequences for the most common TERM= settings (xterm, etc) and can > > query the 'tput' utility for less common ones. > > Before going this route, could you expand on "hardwiring VT220 color > control codes would be bad"? Are there any terminals we actually care > about that this would fail on? I was under the impression that the control codes for 256-color xterm were significantly different than the codes for VT220; for instance. But if the grep and ls maintainers have decided that VT220 codes plus whitelist is good enough for them, then that's good enough for me too. :-) zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: colored diffs [Was: [PATCH] parent selector 'p:xxx']
On Mon, Oct 08, 2007 at 08:32:45PM +0100, Zack Weinberg wrote: > It's a good idea but you need to be careful how you implement it. > Hardwiring VT220 color control codes would be bad. So would making us > depend on ncurses. > > I'd suggest a set of Lua hooks that know the necessary escape > sequences for the most common TERM= settings (xterm, etc) and can > query the 'tput' utility for less common ones. You could also use > this to get at the line-drawing characters for > asciik... Before going this route, could you expand on "hardwiring VT220 color control codes would be bad"? Are there any terminals we actually care about that this would fail on? (Note that the grep and ls maintainers have both answered "no" to this question; search for the string '33[' in their source code. ls at least appears to also have a whitelist of $TERM values that are colorizable, dunno about grep.) -- 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] Re: colored diffs [Was: [PATCH] parent selector 'p:xxx']
On 10/8/07, Ethan Blanton <[EMAIL PROTECTED]> wrote: > > It's a good idea but you need to be careful how you implement it. > > Hardwiring VT220 color control codes would be bad. So would making us > > depend on ncurses. > > ncurses is far less odious than boost -- most systems actually *have* > ncurses, and it doesn't kick compilation times into the stratosphere, > either. ;-) Well, probably it wouldn't be much trouble, but I must point out that GNU ls manages to have optional colorized output without depending on ncurses (however, I have no idea how that feature works). > > I'd suggest a set of Lua hooks that know the necessary escape > > sequences for the most common TERM= settings (xterm, etc) and can > > query the 'tput' utility for less common ones. You could also use > > this to get at the line-drawing characters for > > asciik... > > Down this path lies madness. You're reinventing terminfo. Not so - it's just a more arms-length version of the code we would write if we used ncurses directly. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Break after kill_rev_locally
On 10/8/07, Ludovic Brenta <[EMAIL PROTECTED]> wrote: > "Ralf S. Engelschall" <[EMAIL PROTECTED]> writes: > > > I today had to use "mtn db kill_rev_locally " where was the > > head of a branch. First, everything looked just fine. I freshly checked > > out a new workspace (now based on the previous revision on the branch > > which is now the new head), performed a "mtn log" to be sure that just > > the previous head revision got dropped, etc. Then I edited the sources > > and tried to commit the changes: Bang! > > > > | $ mtn ci -m "adjust key modify commands" > > | mtn: beginning commit on branch 'OSSP.ase.src.TMP.keys' > > | terminate called after throwing an instance of 'std::logic_error' > > | what(): lru_writeback_cache.hh:99: invariant 'I(_dirty.empty())' violated > > | mtn: fatal signal: Abort trap: 6 > > | this is almost certainly a bug in monotone. > > | please send this error message, the output of 'mtn --full-version', > > | and a description of what you were doing to monotone-devel@nongnu.org > > | do not send a core dump, but if you have one, > > | please preserve it in case we ask you for information from it. > > > > The only way to rescue the situation was to restore the database from > > the last UFS snapshot (luckily no other changes happended in the > > meantime) in order to be able to proceed again. > > > > For me this looks like "mtn db kill_rev_locally " does not remove > > _all_ related information of and that some remaining/dangling > > information causes the subsequent commit to break. Hmm... > > > > Unfortunately, I was not able to repeat this with a simple test where I > > created a fresh database, performed three commits and killed the third > > commit :-( > > I had the same, or a very similar symptom after killing the head of a > branch that happened to be a propagate (A to B) node. I then did "mtn > propagate B A" (which was what I really intended) and got an > exception. The killed revision and the new revision had the same > revision ID. > > To correct the problem, I "sync"ed the offending database into a fresh > one and could then proceed with the propagate and commit. > Yep, kill_rev_locally only partially deletes the revision so if you end up trying to commit the same revision id again (or possibly other things) then you get an error. Re-syncing to a new DB should fix it. -- Justin Patrin ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: colored diffs [Was: [PATCH] parent selector 'p:xxx']
Zack Weinberg spake unto us the following wisdom: > On 10/8/07, Lapo Luchini <[EMAIL PROTECTED]> wrote: > > We could, in fact, add a --color option to "mtn diff" itself... > [...] > > Also "mtn log" and "mtn status" would have a big benefit from colors, in > > fact. It could be nice to use them... should probably be off by default, > > but turnable on by default using an hook or something. > > > > Does anyone object if I implement that? ;-) > > It's a good idea but you need to be careful how you implement it. > Hardwiring VT220 color control codes would be bad. So would making us > depend on ncurses. ncurses is far less odious than boost -- most systems actually *have* ncurses, and it doesn't kick compilation times into the stratosphere, either. ;-) I agree that hardcoding escape sequences is a bad idea, but I really think ncurses is the right answer. Worst case scenario, it could be compile-time optional, and color output could simply be ommitted on systems without ncurses (does such a system exist?). > I'd suggest a set of Lua hooks that know the necessary escape > sequences for the most common TERM= settings (xterm, etc) and can > query the 'tput' utility for less common ones. You could also use > this to get at the line-drawing characters for > asciik... Down this path lies madness. You're reinventing terminfo. 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
[Monotone-devel] Re: pulling restricted branches
Tobias Hunger wrote: > mtn: warning: protocol error while processing peer monotone.ca: 'received > network error: anonymous access to branch 'au.asn.ucc.matt.botan.monotone-2' > denied by server' Non every branch is readable anonymously, on that server. > How can I change the default branch pattern used by pull? Manually giving > net.venge.\* after a pull is somewhat tiresome;-) % mtn pull/sync/push --set-default server pattern > How can I find out which branch pattern is currently in use? % mtn ls vars > What is the recommended branch pattern for monotone.ca? net.venge.* seems to > work, but I am afraid to miss out some of the cool new stuff using it;-) I usually use '{net.venge.monotone,net.venge.monotone.*}' which is already more than the simple monotone (some external apps actually reside under that branch). Lapo ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] pulling restricted branches
Hi there! I have trouble pulling from monotone.ca for a while now: Whenever I try to pull from there I end up with this message: mtn: warning: protocol error while processing peer monotone.ca: 'received network error: anonymous access to branch 'au.asn.ucc.matt.botan.monotone-2' denied by server' Afterwards the pull stops (with about 150byte having gone in and out). Would it be possible to have monotone just ignore the branch and continue after giving that warning? How can I change the default branch pattern used by pull? Manually giving net.venge.\* after a pull is somewhat tiresome;-) How can I find out which branch pattern is currently in use? What is the recommended branch pattern for monotone.ca? net.venge.* seems to work, but I am afraid to miss out some of the cool new stuff using it;-) Thanks for your time (and monotone of course!) Best Regards, Tobias ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: colored diffs [Was: [PATCH] parent selector 'p:xxx']
On 10/8/07, Lapo Luchini <[EMAIL PROTECTED]> wrote: > We could, in fact, add a --color option to "mtn diff" itself... [...] > Also "mtn log" and "mtn status" would have a big benefit from colors, in > fact. It could be nice to use them... should probably be off by default, > but turnable on by default using an hook or something. > > Does anyone object if I implement that? ;-) It's a good idea but you need to be careful how you implement it. Hardwiring VT220 color control codes would be bad. So would making us depend on ncurses. I'd suggest a set of Lua hooks that know the necessary escape sequences for the most common TERM= settings (xterm, etc) and can query the 'tput' utility for less common ones. You could also use this to get at the line-drawing characters for asciik... zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Break after kill_rev_locally
"Ralf S. Engelschall" <[EMAIL PROTECTED]> writes: > I today had to use "mtn db kill_rev_locally " where was the > head of a branch. First, everything looked just fine. I freshly checked > out a new workspace (now based on the previous revision on the branch > which is now the new head), performed a "mtn log" to be sure that just > the previous head revision got dropped, etc. Then I edited the sources > and tried to commit the changes: Bang! > > | $ mtn ci -m "adjust key modify commands" > | mtn: beginning commit on branch 'OSSP.ase.src.TMP.keys' > | terminate called after throwing an instance of 'std::logic_error' > | what(): lru_writeback_cache.hh:99: invariant 'I(_dirty.empty())' violated > | mtn: fatal signal: Abort trap: 6 > | this is almost certainly a bug in monotone. > | please send this error message, the output of 'mtn --full-version', > | and a description of what you were doing to monotone-devel@nongnu.org > | do not send a core dump, but if you have one, > | please preserve it in case we ask you for information from it. > > The only way to rescue the situation was to restore the database from > the last UFS snapshot (luckily no other changes happended in the > meantime) in order to be able to proceed again. > > For me this looks like "mtn db kill_rev_locally " does not remove > _all_ related information of and that some remaining/dangling > information causes the subsequent commit to break. Hmm... > > Unfortunately, I was not able to repeat this with a simple test where I > created a fresh database, performed three commits and killed the third > commit :-( I had the same, or a very similar symptom after killing the head of a branch that happened to be a propagate (A to B) node. I then did "mtn propagate B A" (which was what I really intended) and got an exception. The killed revision and the new revision had the same revision ID. To correct the problem, I "sync"ed the offending database into a fresh one and could then proceed with the propagate and commit. -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: colored diffs [Was: [PATCH] parent selector 'p:xxx']
On Mon, Oct 08, 2007, Julio M. Merino Vidal wrote: > [...] > From the screenshots you posted, I don't see how you are piping mtn's > output to your engine. Did you replace the mtn executable with a > script that executes the real one and pipes the output? Yes, OSSP p2 can be either activated via a shell alias (in GNU bash: alias mtn="p2 mtn") or via automatically generated wrapper symlinks (e.g. "p2 --generate ~/.p2/wrapper" plus "PATH=~/.p2/wrapper:$PATH"). For interactively entered commands there is no difference. For indirectly called commands (e.g. "make" executing "gcc" and OSSP p2 should provide error colorization for "gcc") the aliasing doesn't work and the symlink wrappers have to be used. In the screenshots I used the wrapper symlink for "mtn", but the alias would just fine, too. OSSP p2 itself spawns the "mtn" command itself and connects its stdin to the stdin of "mtn" and intercepts the "stdout" and "stderr" of the "mtn" command in an I/O multiplexing way. The this way captured outputs are then passed through one or more plugins which in turn use regular expression based output post-processing. The plugins theirself can be either written programmatically as Perl modules or in a declarative way via an OSSP cfg style configuration file. The "mtn" plugin is coded as a Perl module. After the output post-processing OSSP p2 sends the output to its own stdout and stderr channels. This whole approach is a lot more tricky than it sounds on the first spot because of line-based output buffering, interrupts through signals, the pager has to read interactive keyboard input not from stdin but /dev/tty to not conflict with data for the command on stdin, etc. 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] Re: colored diffs [Was: [PATCH] parent selector 'p:xxx']
On Oct 8, 2007, at 6:22 PM, Ralf S. Engelschall wrote: On Mon, Oct 08, 2007, Julio M. Merino Vidal wrote: On Oct 8, 2007, at 4:04 PM, Lapo Luchini wrote: Lapo Luchini wrote: Derek Scherger wrote: (What's this diffc-0.3 thing?) It's just some perl script that colorizes diffs in a way that seems to look nice. It used to be available at http://download.gnu.org/ diffc-0.3 but I can't seem to get there at the moment. Personally, I use FreeBSD's cdiff (both on FreeBSD and on Cygwin): http://www.freebsd.org/cgi/cvsweb.cgi/ports/textproc/cdiff/src/ We could, in fact, add a --color option to "mtn diff" itself... There are, in fact, two entries in the ROADMAP about this that I added when using cogito in another project. Cogito automatically pages output internally (if the output is directed to a terminal) and has an option to enable colored output for log and diff. These two features were very nice, and hence why I put them in that file ;) Just by coincidence last week I've developed a plugin-based new tool (OSSP p2) which does for Monotone (and also other commands, just according to available plugins) what you all requesting here. If the output is larger than the number of terminal lines, OSSP p2 automatically pages the output, it colorized and even reformats parts of the output, is able to redirect individual lines from stdout to stderr or vice versa, passes though exit codes, correctly handles signals, etc. It finally replaced a bunch of ad-hoc scripts I used since many many years for post-processing and colorizing "cvs diff", "svn diff", "svn log", etc. Ok, OSSP p2 requires Perl and a few addon modules (for terminal independent and not hard-coded coloring, etc), but this doesn't matter very much at least for me ;-) If we insist on having no dependencies for this type of stuff in Monotone, then we have to code this directly into Monotone, of course. But I'm not sure whether it is worth the effort. At least as OSSP p2 is a generic post-processing engine (which just has also a "mtn" plugin), I'm personally also happy with a built-in solution. I append you three ad-hoc made screenshots from my current development session where I today use Monotone (with enabled OSSP p2 for output post-processing) to work on another OSSP tool. In case enough people find this sort of stuff useful I can speed up a little bit in releasing OSSP p2 (the engine and the first set of plugins are done and work fine as you can see in the screenshots -- it just needs more documentation and a little build environment, README, etc)... This seems cool. After some thought, merging all this stuff into Monotone itself might not be a so good idea. From the screenshots you posted, I don't see how you are piping mtn's output to your engine. Did you replace the mtn executable with a script that executes the real one and pipes the output? Thanks, -- Julio M. Merino Vidal <[EMAIL PROTECTED]> ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Break after kill_rev_locally
I today had to use "mtn db kill_rev_locally " where was the head of a branch. First, everything looked just fine. I freshly checked out a new workspace (now based on the previous revision on the branch which is now the new head), performed a "mtn log" to be sure that just the previous head revision got dropped, etc. Then I edited the sources and tried to commit the changes: Bang! | $ mtn ci -m "adjust key modify commands" | mtn: beginning commit on branch 'OSSP.ase.src.TMP.keys' | terminate called after throwing an instance of 'std::logic_error' | what(): lru_writeback_cache.hh:99: invariant 'I(_dirty.empty())' violated | mtn: fatal signal: Abort trap: 6 | this is almost certainly a bug in monotone. | please send this error message, the output of 'mtn --full-version', | and a description of what you were doing to monotone-devel@nongnu.org | do not send a core dump, but if you have one, | please preserve it in case we ask you for information from it. The only way to rescue the situation was to restore the database from the last UFS snapshot (luckily no other changes happended in the meantime) in order to be able to proceed again. For me this looks like "mtn db kill_rev_locally " does not remove _all_ related information of and that some remaining/dangling information causes the subsequent commit to break. Hmm... Unfortunately, I was not able to repeat this with a simple test where I created a fresh database, performed three commits and killed the third commit :-( 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] Re: colored diffs [Was: [PATCH] parent selector 'p:xxx']
On Oct 8, 2007, at 4:04 PM, Lapo Luchini wrote: Lapo Luchini wrote: Derek Scherger wrote: (What's this diffc-0.3 thing?) It's just some perl script that colorizes diffs in a way that seems to look nice. It used to be available at http://download.gnu.org/ diffc-0.3 but I can't seem to get there at the moment. Personally, I use FreeBSD's cdiff (both on FreeBSD and on Cygwin): http://www.freebsd.org/cgi/cvsweb.cgi/ports/textproc/cdiff/src/ We could, in fact, add a --color option to "mtn diff" itself... There are, in fact, two entries in the ROADMAP about this that I added when using cogito in another project. Cogito automatically pages output internally (if the output is directed to a terminal) and has an option to enable colored output for log and diff. These two features were very nice, and hence why I put them in that file ;) -- Julio M. Merino Vidal <[EMAIL PROTECTED]> ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: [PATCH] parent selector 'p:xxx'
Lapo Luchini spake unto us the following wisdom: > Ethan Blanton wrote: > > Even when it is correct, for > > Pidgin it often has 3-5 parallel lines at two columns apiece, and > > often it mistakenly draws O(a lot) of parallel lines. > > BTW: As far as correctness goes, I think it is correct. > The "problem" is it is usually run on a restricted set of nodes and > proper use of "daggy fixes" lead to merges with very old nodes (and thus > very long arcs in the overall DAG). In this case, correct is in the eye of the beholder. It might be technically correct, but still be presenting useless information which makes it functionally incorrect. As an example, if I log only a dozen revisions, and there is only one divergence and merge within those dozen revisions, there should be no more than two lines -- but sometimes there will be tens of lines from the first revision to the very last, representing (I presume) parallel and unrelated divergences. I think Richard Levitte sent an example of this to the list, some time back. That said, there are places in the Pidgin history where the graph code shows tens of parallel revisions, where monotone-viz shows two or three -- they can't both be right, if they are both displaying the same data. ;-) 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
[Monotone-devel] Re: colored diffs [Was: [PATCH] parent selector 'p:xxx']
Lapo Luchini wrote: > Derek Scherger wrote: >>> (What's this diffc-0.3 thing?) >> It's just some perl script that colorizes diffs in a way that seems to >> look nice. It used to be available at http://download.gnu.org/diffc-0.3 >> but I can't seem to get there at the moment. > > Personally, I use FreeBSD's cdiff (both on FreeBSD and on Cygwin): > http://www.freebsd.org/cgi/cvsweb.cgi/ports/textproc/cdiff/src/ We could, in fact, add a --color option to "mtn diff" itself... Pro: no need to have perl, no need to constantly pipe things Cons: probably need an external one in the system anyway Also "mtn log" and "mtn status" would have a big benefit from colors, in fact. It could be nice to use them... should probably be off by default, but turnable on by default using an hook or something. Does anyone object if I implement that? ;-) Lapo ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Further update to notification script
On Mon, Oct 08, 2007 at 02:10:28AM -0700, Nathaniel Smith wrote: > Seems like you should just get commit access to me... Who's in charge > of adding people to the server these days? Richard? I did used to have commit access - I definately sent my pubkey to Richard a while back. But then after the servers changed I think my write access was removed/lost, which is fair enough as I hadn't done any work for some time... Matthew ___ 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 Sun, Oct 07, 2007 at 09:58:14PM -0600, Derek Scherger wrote: > Ethan Blanton wrote: > > > I believe that it should; if it is more than just a few columns wide, > > it tends to make diffs and commit messages wrap on terminals they are > > meant to accommodate, and it displays an unfortunate tendency to be > > far more than a "few" columns wide. Even when it is correct, for > > Pidgin it often has 3-5 parallel lines at two columns apiece, and > > often it mistakenly draws O(a lot) of parallel lines. This seems fixable -- we know how wide the terminal is (the ticker code needs this), we know that the graph becomes *completely* useless when wrapping happens, so we can just teach monotone to do the Right Thing (i.e. disable the graph when it gets too wide, perhaps only for portions of time when it is too wide). There are a lot of other ways that the graphs are not as smart as they could be, and currently require --no-graph -- e.g., if you use --no-merges (like one of the examples upthread) then right now you basically have to use --no-graph. So that's easy to make right-by-default too. The other example given was as part of a hack to create a command that mtn should have anyway -- so when we add that command, that need for --no-graph will disappear as well. The graphs would also be more useful if log output were shorter (and esp. the merge output were less completely stupid than it is now -- showing every file touched on either side of the merge makes No Sense). > Another thought. Maybe what we really need is something like .csvrc > where you can specify the default options that you generally want with > specific commands. I'm not sure how you would occasionally un-set > options that were set like this though. This would be an easy way to make this problem go away, but I'm not convinced that it's the correct one. It seems to me that the problems with the graphs are more specific, and fixable as such. -- Nathaniel -- "If you can explain how you do something, then you're very very bad at it." -- John Hopfield ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Further update to notification script
Seems like you should just get commit access to me... Who's in charge of adding people to the server these days? Richard? On Mon, Oct 08, 2007 at 08:33:16AM +0100, Matthew Sackman wrote: > This morning my mailbox was full of error reports - I wasn't caching the > current time but looking it up twice and of course it can change. So > he's a patch to fix that and I've also updated the README file for > contrib. Could someone commit the patch please? > > Many thanks, > > Matthew > -- > Matthew Sackman > http://www.wellquite.org/ > # > # old_revision [4c7504ea753f15bde2abc80e0e74dfc0951735e4] > # > # patch "contrib/README" > # from [a5a965b9b3fed717621b8c216ec226756a95e568] > #to [9c675c56a2e014932a16079f1a580b427c2cff15] > # > # patch "contrib/monotone-mail-notify-standalone.lua" > # from [b451b8b6da1a0f92dcb9d372fe1935972f9eafaa] > #to [f7912c79e41bff48c12b54e25bad92a03d5bc031] > # > > --- contrib/READMEa5a965b9b3fed717621b8c216ec226756a95e568 > +++ contrib/README9c675c56a2e014932a16079f1a580b427c2cff15 > @@ -64,7 +64,10 @@ See individual files for licenses. > for use. > >-- monotone-mail-notify-standalone.lua: a mail notification script which > - runs without any other external dependencies than /usr/bin/mail and > offers an individual per-branch recipient configuration with a syntax > - similar to the one found in ~/.monotone/read-permissions > + similar to the one found in ~/.monotone/read-permissions. > + It writes out details of each revision received to files which are then > + picked up by the monotone-mail-notify-standalone.sh script which > requires > + shell, source-highlight and mime-construct to build nicely structured > + emails with summaries of the revision and its diffs. > > > --- contrib/monotone-mail-notify-standalone.lua > b451b8b6da1a0f92dcb9d372fe1935972f9eafaa > +++ contrib/monotone-mail-notify-standalone.lua > f7912c79e41bff48c12b54e25bad92a03d5bc031 > @@ -133,9 +133,11 @@ do > if j < # (rev_data["certs"]["author"]) then reply_to = > reply_to .. ", " end > end > > -local outputFileRev = io.open(_base .. rev_data["revision"] .. > os.time() .. ".rev.txt", "w+") > -local outputFileHdr = io.open(_base .. rev_data["revision"] .. > os.time() .. ".hdr.txt", "w+") > +local now = os.time() > > +local outputFileRev = io.open(_base .. rev_data["revision"] .. > now .. ".rev.txt", "w+") > +local outputFileHdr = io.open(_base .. rev_data["revision"] .. > now .. ".hdr.txt", "w+") > + > local to = "" > for j,addr in pairs(rev_data["recipients"]) do > to = to .. addr > ___ > Monotone-devel mailing list > Monotone-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/monotone-devel -- Nathaniel -- So let us espouse a less contested notion of truth and falsehood, even if it is philosophically debatable (if we listen to philosophers, we must debate everything, and there would be no end to the discussion). -- Serendipities, Umberto Eco ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Further update to notification script
On Mon, Oct 08, 2007 at 10:25:21AM +0200, Thomas Keller wrote: > Applied in 3ae9515ab35b20ff8b04376fd768ccb867f233af, I also renamed the > files and removed the -standalone part we've talked about. Many thanks indeed. Matthew -- Matthew Sackman http://www.wellquite.org/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Further update to notification script
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Matthew Sackman schrieb: > This morning my mailbox was full of error reports - I wasn't caching the > current time but looking it up twice and of course it can change. So > he's a patch to fix that and I've also updated the README file for > contrib. Could someone commit the patch please? Applied in 3ae9515ab35b20ff8b04376fd768ccb867f233af, I also renamed the files and removed the -standalone part we've talked about. Thomas. - -- only dead fish swim with the stream: http://thomaskeller.biz/blog Am Anfang war das Wort: http://www.schäuble-muss-weg.de -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHCelxaf7NlBYNEJIRAgSuAKDoAcF/cf0Nh9xJXb3uTdEUE7IRRACdG7jg 5QVwuuYFnRgQ7LTukSxACuA= =iz3C -END PGP SIGNATURE- ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: [PATCH] parent selector 'p:xxx'
Ethan Blanton wrote: > Even when it is correct, for > Pidgin it often has 3-5 parallel lines at two columns apiece, and > often it mistakenly draws O(a lot) of parallel lines. BTW: As far as correctness goes, I think it is correct. The "problem" is it is usually run on a restricted set of nodes and proper use of "daggy fixes" lead to merges with very old nodes (and thus very long arcs in the overall DAG). Lapo ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] colored diffs [Was: [PATCH] parent selector 'p:xxx']
Derek Scherger wrote: >> (What's this diffc-0.3 thing?) > > It's just some perl script that colorizes diffs in a way that seems to > look nice. It used to be available at http://download.gnu.org/diffc-0.3 > but I can't seem to get there at the moment. Personally, I use FreeBSD's cdiff (both on FreeBSD and on Cygwin): http://www.freebsd.org/cgi/cvsweb.cgi/ports/textproc/cdiff/src/ Lapo ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: [monotone wiki] Änderung von "ISO14000 环境管理体系认证的意义" von 521jin gke8866
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all! Could we please do something permanently against the recent spam flood in the wiki? I'd vote for disabling anonymous edits, but if anyone has some time (and access to the wiki) to play with akismet or else, feel free. Thomas. - -- only dead fish swim with the stream: http://thomaskeller.biz/blog Am Anfang war das Wort: http://www.schäuble-muss-weg.de -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHCeOMaf7NlBYNEJIRAii6AJ9IXA3uaHn2nXtbYrUZQewam8VjDACgswAn ZYwyLNwbkliPu08hnac64ys= =kKrg -END PGP SIGNATURE- ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Further update to notification script
This morning my mailbox was full of error reports - I wasn't caching the current time but looking it up twice and of course it can change. So he's a patch to fix that and I've also updated the README file for contrib. Could someone commit the patch please? Many thanks, Matthew -- Matthew Sackman http://www.wellquite.org/ # # old_revision [4c7504ea753f15bde2abc80e0e74dfc0951735e4] # # patch "contrib/README" # from [a5a965b9b3fed717621b8c216ec226756a95e568] #to [9c675c56a2e014932a16079f1a580b427c2cff15] # # patch "contrib/monotone-mail-notify-standalone.lua" # from [b451b8b6da1a0f92dcb9d372fe1935972f9eafaa] #to [f7912c79e41bff48c12b54e25bad92a03d5bc031] # --- contrib/README a5a965b9b3fed717621b8c216ec226756a95e568 +++ contrib/README 9c675c56a2e014932a16079f1a580b427c2cff15 @@ -64,7 +64,10 @@ See individual files for licenses. for use. -- monotone-mail-notify-standalone.lua: a mail notification script which - runs without any other external dependencies than /usr/bin/mail and offers an individual per-branch recipient configuration with a syntax - similar to the one found in ~/.monotone/read-permissions + similar to the one found in ~/.monotone/read-permissions. + It writes out details of each revision received to files which are then + picked up by the monotone-mail-notify-standalone.sh script which requires + shell, source-highlight and mime-construct to build nicely structured + emails with summaries of the revision and its diffs. --- contrib/monotone-mail-notify-standalone.lua b451b8b6da1a0f92dcb9d372fe1935972f9eafaa +++ contrib/monotone-mail-notify-standalone.lua f7912c79e41bff48c12b54e25bad92a03d5bc031 @@ -133,9 +133,11 @@ do if j < # (rev_data["certs"]["author"]) then reply_to = reply_to .. ", " end end -local outputFileRev = io.open(_base .. rev_data["revision"] .. os.time() .. ".rev.txt", "w+") -local outputFileHdr = io.open(_base .. rev_data["revision"] .. os.time() .. ".hdr.txt", "w+") +local now = os.time() +local outputFileRev = io.open(_base .. rev_data["revision"] .. now .. ".rev.txt", "w+") +local outputFileHdr = io.open(_base .. rev_data["revision"] .. now .. ".hdr.txt", "w+") + local to = "" for j,addr in pairs(rev_data["recipients"]) do to = to .. addr ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: 0.36 error on cygwin
Lapo Luchini wrote: > $ mtn -d .monotone/it.lapo.mtn --debug pull lapo.it it.lapo.homedir > [...] > mtn: searching for '_MTN' directory with root '/' > mtn: '_MTN' not found in '/home/lapo' with '' removed > mtn: '_MTN' not found in '/home' with 'lapo' removed > mtn: /home/lapo/packaging/tmp/monotone-0.36/unix/fs.cc:124: detected > error 'E(false)' violated > mtn: [...] > mtn: error: error accessing file //_MTN: No such host or network path Fixed. Please someone take a look at: % mtn diff -r 4c7504ea -r 22a49837 (I will take a look at buildbots after the propagation, anyway...) Lapo ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel