gmane.comp.version-control.monotone.devel

Re: nvm.resolve_conflicts ready to land on mainline

Stephen Leake — 2008-11-17T01:04:04

Ok, good. You might be able to program this in Lua, in the merge hook. Ah, I see. Yes, a random name could be generated. But (in my system, with my mtn hook settings), this will run emacs ediff. I prefer meaningful file names in that case, and you don't want to default to an existing file. I suppose the filename could be optional; use a random one if none given. I think that's the kind of tweaking that can be done after merging to main, and after more people get more experience with this. I'll merge this into main next weekend, if no other objections crop up.

monotone-0.41 compile failure withglibc(disabled-nls)

Daniel Black — 2008-11-16T18:17:49

_______________________________________________ Monotone-devel mailing list Monotone-devel< at >nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: nvm.resolve_conflicts ready to land on mainline

Tero Koskinen — 2008-11-16T19:48:12

Hi, On Sat, 08 Nov 2008 14:25:55 -0500 Stephen Leake wrote: Yes. The conflicts command set is definately an improvement over the current situation. Darcs' UI follows form: info rmat ion Question? [snoitpn]: For example: **snip** $ darcs record hunk ./index.html 13 -

- Shall I record this change? (1/1) [ynWsfvpxdaqjk], or ? for help: y What is the patch name? Remove extra div Do you want to add a long comment? [yn]n Finished recording patch 'Remove extra div' $ **snip** And mergemaster: info rmat ion [1] option 1 [2] option 2 [3] option 3 Question? Example: **snip** ===> Displaying differences between ./etc/changelist and installed version: --- /etc/changelist Sun Aug 31 11:54:38 2008 +++ ./etc/changelist Sat Nov 1 20:41:12 2008 < at >< at > -1,4 +1,4 < at >< at > -# $OpenBSD: changelist,v 1.58 2008/06/13 00:46:57 ajacoutot Exp $ +# $OpenBSD: changelist,v 1.59 2008/10/02 07:27:57 sthen Exp $ # # List of files which the security script backs up and checks # for

Re: weird monotone behavior

Timothy Brownawell — 2008-11-16T17:25:35

It should catch this now, since e0bb897ff4a5944db2e6dd13c3b809855a2c6f80 (a couple minutes ago).

Re: weird monotone behavior

Nathaniel Smith — 2008-11-16T04:21:51

I bet this is the bit where the basic_io code was partly designed for files that mix multiple basic_io formats, and you need to greedily eat all you can of one format and then cleanly return for the next guy in the chain to keep going (think of e.g., extracting a changeset from a revision). So it saw a string "/local_home/hugo/neurospaces_project/MTN/neurospaces-developer.mtn\n branch", followed by an unrecognized token "0", and since that was unrecognized, stopped parsing there. So it thought that the branch was just unspecified, which is legal, and that's what it wrote back out. Guess we need a "assert that's the end of the file" operation in the basic_io interface.

Re: weird monotone behavior

Hugo Cornelis — 2008-11-16T02:46:16

Thanks for the fast answer, I should have spotted this myself. As you say it would be good if monotone handles this error condition in a more graceful way, it still makes me feel a bit uncomfortable. Likely that manual editing is the root cause of the problem. Thanks for the answer. Hugo On Sat, Nov 15, 2008 at 8:35 PM, Timothy Brownawell prjek.net> wrote: Hugo -- Hugo Cornelis Ph.D. Neurospaces Project Architect http://www.neurospaces.org/ Research Imaging Center University of Texas Health Science Center at San Antonio 7703 Floyd Curl Drive San Antonio, TX 78284-6240 Phone: 210 567 8112 Fax: 210 567 8152

Re: weird monotone behavior

Timothy Brownawell — 2008-11-16T02:35:53

There's no closing '"' on the database line, so really the options file is already invalid. It *should* give an error when trying to parse _MTN/options (and then not overwrite it), and in fact it *does* give an error if I try the same thing with branch "x" instead of branch "0" . So apparently the basic_io parser can fail to detect certain error conditions...

weird monotone behavior

Hugo Cornelis — 2008-11-16T02:22:14

Hi, I am using monotone 0.40 statically linked, downloaded from the monotone website on a redhat enterprise server 5. I encountered the following problem: I have a project that uses a database ~/neurospaces_project/MTN/installer.mtn I pulled an external database of the same project to ~/neurospaces_project/MTN/neurospaces-developer.mtn Changed the options files in a workspace, then did the things below. In a summary, after changing the option file, asking for a log overwrites the options file and makes it invalid. Changing back to the original database did not help. Not sure if I am doing something wrong, but monotone making the options file invalid makes me feel uncomfortable :( [19:46] (0,2) 0 $ cat _MTN/options database "/local_home/hugo/neurospaces_project/MTN/neurospaces-developer.mtn branch "0" [19:46] (0,2) 0 $ mtn log --debug mtn: searching for '_MTN' directory with root '/' mtn: working root is '/local_home/hugo/neurospaces_project/installer/source/snapshots/0' mtn: initial relative path i

Re: heads up on nvm.stripped

Jack Lloyd — 2008-11-13T16:49:21

Many of the changes in the last few releases were made specifically with regards to what mtn needs re SHA-1, since mtn has been a sort of acid test application so far in terms of botan's performance abilities. So hopefully they will actually prove useful in Monotone. But waiting for 1.8 to be released and widely included in distros doesn't seem like a bad idea. Good point, I had not considered caching the result but that does make sense. I like _MTN/options for this. benchmark_sha1 could optionally update _MTN/options with the fastest provider. -Jack

Re: heads up on nvm.stripped

Markus Wanner — 2008-11-13T16:26:48

Hi, Jack Lloyd wrote: Very cool, thank you. FYI, my Core (1) Duo reports: mtn: Benchmarking botan's SHA-1 core mtn: SHA-1 provider 'core': 117.172 MiB/s mtn: SHA-1 provider 'ia32': 135.325 MiB/s That's fine. I fear the #ifdef's are not quite enough. We'd have to check for the botan version dynamically. So I'd say we better wait a bit until that API stabilizes. ..or even store the setting in _MTN/options because such a benchmark might not pay-off every time mtn is invoked. Alternatively have it stored in monotonerc and set as a system config during installation of monotone. Storing in _MTN/options sounds easier to automate, so I'm currently favoring that variant. Regards Markus Wanner

Re: heads up on nvm.stripped

Jack Lloyd — 2008-11-12T19:23:53

I've attached a patch for sha1.cc demoing the new benchmark code. For informative purposes only, since it currently only works on an unreleased version (future 1.7.22, nrb head), and API-wise things are still in flux in this area. In the future it may be useful to extend Monotone to run a quick test and then choose the fastest SHA-1 provider to use for the rest of the program run. 20 milliseconds of benchmark time at startup could pay for itself quickly in many cases. -Jack $ ./mtn version --full monotone 0.41 (base revision: c18c4c9d2fbcdaaf08fb448837b778e6f30968a6) Running on : Linux 2.6.27-gentoo-3 #5 SMP Thu Oct 16 15:40:05 EDT 2008 x86_64 C++ compiler : GNU C++ version 4.3.2 C++ standard library: GNU libstdc++ version 20080827 Boost version : 1_35 SQLite version : 3.5.9 (compiled against 3.5.9) Lua version : Lua 5.1 PCRE version : 7.8 2008-09-05 (compiled against 7.8) Botan version : 1.7.22 (compiled against 1.7.22) Changes since base revision: unknow

heads up on nvm.stripped

Markus Wanner — 2008-11-12T18:19:06

Hi, I've upgraded and tested nvm.stripped with the recently announced botan 1.7.21 and SQLite 3.6.5. The code to switch sha1 engines within monotone caused problems with the newer botan release. As we do not use that code anywhere except for the benchmark_sha1 command, I've simply removed it. It rather looks like botan offers something similar to benchmark various sha1 engines. I didn't look into that, though, but don't think we need to duplicate that work. nvm.stripped now compiles fine and passes all tests again. Regards Markus Wanner monotone 0.41 (base revision: c18c4c9d2fbcdaaf08fb448837b778e6f30968a6) Running on : Linux 2.6.24-rc7-cametha #1 SMP Mon Jan 14 15:31:35 CET 2008 i686 C++ compiler : GNU C++ version 4.3.2 C++ standard library: GNU libstdc++ version 20080905 Boost version : 1_34_1 SQLite version : 3.6.5 (compiled against 3.6.5) Lua version : Lua 5.1 PCRE version : 7.6 2008-01-28 (compiled against 7.6) Botan version : 1.7.21 (compiled agai

Re: Re: Summit thoughts - and changes?

Markus Wanner — 2008-11-12T12:11:22

Hi, Lapo Luchini wrote: Works for me as well. Although I cannot promise to be available all weekend long. Regards Markus Wanner

Re: [RFC] mtn to git conversion script

Juan Jose Comellas — 2008-11-11T16:30:53

_______________________________________________ Monotone-devel mailing list Monotone-devel< at >nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: making I(), E(),N() throw bad_decode for network data

Stephen Leake — 2008-11-11T12:07:27

This sounds good. One downside is a lot of functions will now require an 'origin' parameter to pass to the sanity macro.

Re: making I(), E(),N() throw bad_decode fornetwork data

Timothy Brownawell — 2008-11-11T01:54:37

Maybe, but there are some complications. One would be that we probably don't want the server to catch *all* cases of a malformed revision, just those that came from the network. If we read a garbage revision from the db we probably want to crash with a debug log regardless of what code ran to get us there. I suppose this could probably be handled with a flag in the thrown exception to indicate the source of the bad data. Another is that checks would suddenly be a lot less convenient to write than they are now. Instead of just "I(condition)" you'd also have to give the proper exception type and probably an origin flag. But if the origin flag could also be "user", hmm, we effectively get to choose between I(), E(), and N() at runtime based on the source of the bad data... How about two sanity macros, and probably two or three exception types. One that's like I() is now, but only for verifying things that could not possibly have come from "outside" (which would include coming from the database). And one to

Re: making I(), E(), N() throw bad_decode fornetwork data

Timothy Brownawell — 2008-11-11T01:04:19

Yes, its purpose is to be caught where it can terminate a particular connection without killing the entire process. The netsync code and a few places that are only called from there actually do throw bad_decode directly instead of using the sanity macros for data errors. Yes, that's what I'm trying to address here. If we have malformed basic_io, or a "revision" that actually isn't, or a file that doesn't match the given hash... the code that finds these errors is the same whether the data was generated internally or from the database, or came from the network.

Re: making I(), E(), N() throw bad_decode for networkdata

Thomas Keller — 2008-11-10T12:15:42

_______________________________________________ Monotone-devel mailing list Monotone-devel< at >nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: making I(), E(),N() throw bad_decode for network data

Stephen Leake — 2008-11-10T12:06:09

I gather the network sync code handles bad_decode gracefully. We could define a new set of macros to use in the network sync code. But I guess that doesn't help if the network code calls a function from another file that uses the standard macros.

making I(), E(),N() throw bad_decode for network data

Timothy Brownawell — 2008-11-10T04:26:59

It's possible to I() a server by sending invalid data, this actually happened here when merge_into_dir came out and not-up-to-the-minute versions thought the resulting revisions were bogus. I've just pushed a revision that makes the sanity macros look at a 'made_from' value, and throw bad_decode instead of their normal behavior if that value is set to made_from_network. ATOMIC and ENCODING types and revision_t have a member like this, and revision_t rev; rev.made_from = made_from_network; read_revision(garbage_data, rev); does actually throw bad_decode now for at least some kinds of garbage. I don't particularly like having the macros take a "hidden" argument like this, but I'm not sure what would be better. Having them call some function that you can declare in your class seems slightly cleaner, but that wouldn't allow things like made_from_t made_from(rev.made_from); I(rev.new_manifest == roster_manifest_id); (database::put_roster_for_revision) and keeping the function call inside the condition chec

Re: nvm.resolve_conflicts ready to land on mainline

Stephen Leake — 2008-11-08T19:25:55

Thanks for looking at this. good. Thanks. Thanks. Was it more comfortable than the standard "here's another file to merge" approach? Can you give an example of how the menus in those tools work? I don't have them installed, and I'd rather not try to figure out how to use them just for this. No other commands in mtn present menus. I'm not inclined to start adding that functionality. I prefer to add functionality in Gnu Emacs DVC for a better interface to mtn conflicts. Ok, I'll add tests for all the mtn conflicts commands for number of args. There are two files, one from each revision. You arbitarily choose the left, when the user might want the right one. I don't think it's a good idea to default this. Not directly in HACKING (I searched for "length"). However, that references the "Gnu coding standards", without a URL. A quick web search found http://www.gnu.org/prep/standards/ . A quick look there turned up no line length limit. But maybe I missed something. I prefer a line length limit