Re: [Monotone-devel] possible SSL compromise
Hello, On Tue, Apr 8, 2014 at 9:25 PM, Hendrik Boom hend...@topoi.pooq.com wrote: I've just heard about a potential vulnerability in OpenSSL. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743883 for the Debian version of this problem. In particular, the message states all keys used with vulnerable processes will need to be replaced both in Debian infrastructure and by all users of this package. I'm wondering whether monotone use is affected by this problem. Monotone doesn't use TLS and thus openssl implemtentation of TLS and the bug in question specific to TLS _extension implementation_ in openssl. This is plain old buffer overrun, or in this case buffer overrun ... [1] I don't know if it even uses OpenSSL No, it uses botan but only for primitive crypto methods. Monotone's netsync protocol and it's implementation has other ... yet unknown bugs :) [1] thorough bug analyssis for curious: http://blog.existentialize.com/diagnosis-of-the-openssl-heartbleed-bug.html -- Zbigniew Zagórski / software developer / geek / http://zbigg.blogspot.com / ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] capacity
Hello, On Mon, Jul 15, 2013 at 7:24 PM, Hendrik Boom hend...@topoi.pooq.com wrote: Just wondering -- is there a limit on the size of a monotone repository? I figure it's limited by the maximum file size on the file system, but now that those limits have gone way over 4 gigabytes, has monotone's data base backend kept up? Monotone uses sqlite3, and it's limits are described here: http://www.sqlite.org/limits.html. Page size of monotone db is 8192 (at least my databases are something like that), max database size is something like 8192 * 2^31 should be enough for any sane monotone database. So in theory it should handle huge databases ... -- Zbigniew Zagórski / software developer / geek / http://zbigg.blogspot.com / ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] code.monotone.ca problems
Hi, Some projects under code.monotone.ca are suffering from 500 internal server error. Looks like monotone server is down also: $ mtn pull mtn://monotone.ca/monotone?* mtn: doing anonymous pull; use -kKEYNAME if you need authentication mtn: connecting to 'mtn://monotone.ca/monotone' mtn: include pattern '*' mtn: exclude pattern '' mtn: received warning from usher: Cannot fork server. -- Zbigniew Zagórski / software developer / geek / http://zbigg.blogspot.com / ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] monotone-subversion sync
Hi, Regards, Zbyszek On Thu, Jan 19, 2012 at 4:52 PM, Jerome Baum jer...@jeromebaum.com wrote: Hey, What's the best/recommended option for keeping monotone in sync with a subversion repository? I've tried tailor but it barks during the initial svn-mtn transform. Apart from that I couldn't find much to go by. hg converts from mtn to hg, and from svn to hg, so maybe combined with tailor that might work -- but I first wanted to ask for input. I think that we have only tailor :/ I am doing it all the time using tailor and it works for me. [and thus I have some moderate experience with issues jiding here and there) ] So please describe your problems a little more so maybe i can help you. (BTW, here is example of my tailor config script that runs it: http://code.google.com/p/tinfra/wiki/TailorForGoogle) -- Zbigniew Zagórski / software developer / geek / http://zbigg.blogspot.com / ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] dump/nuskool transport protocol revival
Hi, Just a small query or heads up request about easier setup of monotone servers. Now when we have netsync, it is sometimes PITA to setup synchronization (unless ssh is in place). We had this dumb protocol and implementation in python [1] that served me well for some time but now it is abandoned; and what is more important it is not available to anyone except me and maybe some hardcore archeologist who remembers monotone history. Is there any interest in having this reliable (but not high performance) HTTP/SFTP synchronization transport for monotone ? I even thought about implementing in in core of monotone but actually at that time nuskool was the way to go ... but the nuskool is far from ready (and AFAIR requires policy branches)... dumb is ready and can be available in week (as python) in few months (as native solution) [I know about nuskool but i don't remembers what was significant difference from dumb protocol] (tigger for this discussion: i just lost my monotone central repository manager by usher :/ and thus lost any _sane_ option to synchronize windows boxes :/ ...) [1] https://code.monotone.ca/p/monotone/source/tree/h:net.venge.monotone.dumb/ -- Zbigniew Zagórski / software developer / geek / http://zbigg.blogspot.com / ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Fwd: [Monotone-devel] monotone 0.48.1 released
Hi, (resending to list) On Fri, Oct 22, 2010 at 2:43 PM, Thomas Moschny thomas.mosc...@gmx.de wrote: Hi! This is to announce that we, the monotone developers, have released version 0.48.1 of our distributed version control system. Good news thanks! As usual i've build win32 setup package for this release, but looks like my ssh key disappeared from mtn-uplo...@monotone.ca .ssh/authorized_keys. What is the method for upload now? (I've tried: scp monotone-0.48.1-setup.exe mtn-uplo...@monotone.ca:downloads/0.48.1 ) Should I resent the key or how should we publish packages now? -- Zbigniew Zagórski / software developer / geek / http://zbigg.blogspot.com / -- Zbigniew Zagórski / software developer / geek / http://zbigg.blogspot.com / ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] removal of packet functions
Hello, New thread for new issue discussed: On Tue, Jul 6, 2010 at 9:22 AM, Thomas Keller invalid.nore...@gnu.org wrote: Follow-up Comment #3, bug #30345 (project monotone): I forgot one thing - given the fact that we want to deprecate / remove the packet functions (at least for revisions, certs, files and file deltas) on the long run, we _might_ not want to use read_packets for put_public_key. The removal of the packet functions is on the roadmap for a long time - I don't know if people still use these functions at all. Hello, nvm.dumb still uses this - although it's now a little outdated now. That means i still use it from time to time to synchronize via sftp/http ... (well i haven't published my work anywhere that's a fact). (Giving that we wait and wait for nuskool/policy branches for years nvm.dumb is the only solution for synchronization when netsync doesn't work). Do you have any technical issue with packet stuff ? I do like it :) Greetings, -- Zbigniew Zagórski / software developer / geek / http://zbigg.blogspot.com / ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] monotone 0.48 released
On Mon, Jun 14, 2010 at 12:55 AM, Thomas Keller m...@thomaskeller.biz wrote: Hi! We, the monotone developers, are very proud to announce the new 0.48 release of our distributed version control system. Thanks for your work! Windows version is available. -- Minor heads up for release manager. t:monotone-0.48 doesn't build on win32 because of compilation error. Error is trivial (patch attached) and Windows version of monotone-0.48 will not exactly match revision tagged as monotone-0.48. (anyone who made this change in win32/parse_date.cc ... if you don't have win32 build env in under your hand please ping me even using private e-mail and i can recheck build before release, unfortunately i can't supply mingw32 buildbot). -- Zbigniew Zagórski / software developer / geek / http://zbigg.blogspot.com / monotone_0.48_mingw_fix.patch Description: Binary data ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time for a release
Hi, 2010/5/31 Zbigniew Zagórski z.zagor...@gmail.com: 2010/5/31 Thomas Keller m...@thomaskeller.biz: 1) The Debian testing one seems to have update problems from time to time and complains about no rule to make the target `win32/monotone.iss' for `distdir'. Zbigniew, could you please have a look? My fault - thanks for poiting this out (I should have grep for users of this file before making it generated). monotone.iss is explicitly specified in EXTRA_DIST. I will correct it this evening. Fixed. Sorry for problem! -- Zbigniew Zagórski / software developer / geek / http://zbigg.blogspot.com / ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time for a release
Hi! 2010/5/31 Thomas Keller m...@thomaskeller.biz: Hi all! Its release time, again :), and I would like you to look over the translations and build bots and get them in a good and usable state. I am wondering if we can safely use gcc-4.5.0 to build Windows native version of monotone. Current status is that almost all (lua locale issue again) tests are passing. For those interested in testing stability of new build chain, there is updated setup of 0.47 in downloads. http://monotone.ca/downloads/0.47/monotone-0.47-gcc450-setup.exe I just think that it might be good to check if new compilation environment doesn't bring any surprises. 1) The Debian testing one seems to have update problems from time to time and complains about no rule to make the target `win32/monotone.iss' for `distdir'. Zbigniew, could you please have a look? My fault - thanks for poiting this out (I should have grep for users of this file before making it generated). monotone.iss is explicitly specified in EXTRA_DIST. I will correct it this evening. -- Zbigniew Zagórski / software developer / geek / http://zbigg.blogspot.com / ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] usabilty of translations
Hi, What do you think about internalization of software like monotone ? I know that there are few localizations (currently INST_LINGUAS = sv it de es pt). I am wondering if there is for more translation - at least I can easily add polish translation. But i am worried about two things: 1) Would anyone use it ? I know that amongst developers (at least professional ones), there is strong movement to use english-only UI/termsinstead native ones - ad-hoc created terms create only confusion and thus are problematic (at least polish IT/CS terminology/vocabulary is week) . YYMV but in my experience- use only english terms. So then ... I this experience is similar to yours? 2) Do you encountered any non-developer users of monotone or VSC / SCM who would need / understand and use these ideas ? Do you (authors of these translations) use them ? And last final question: Are there any polish people on list who would like to see polish messages in monotone UI? -- Zbigniew Zagórski / software developer / geek / http://zbigg.blogspot.com / ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: monotone.ca nvm: pull fails on invariant
Hello again, W dniu 29 maja 2010 02:54 użytkownik Zbigniew Zagórski z.zagor...@gmail.com napisał: I can't pull nvm branch from any server (both monotone.ca and monotone.mtn-host.prjek.net) [1] $ mtn pull monotone.ca 'net.venge.monotone' (...) mtn: 251.3 k | 107.7 k | 78/152 | 27/48 mtn: fatal: error: graph.cc:99: I(!next.empty()) Just for record, this was my local issue. Later i've executed mtn db check and it yielded something like this $ mtn -d monotone-bad.mtn db check mtn: mtn: mtn: revision 0e67b65edabb68ee96fe6d4eff5a32c3da79b013 incomplete (1 missing manifests) mtn: revision 0e67b65edabb68ee96fe6d4eff5a32c3da79b013 incomplete (missing roster) mtn: revision 0e67b65edabb68ee96fe6d4eff5a32c3da79b013 missing author cert mtn: revision 0e67b65edabb68ee96fe6d4eff5a32c3da79b013 missing changelog cert mtn: revision 0e67b65edabb68ee96fe6d4eff5a32c3da79b013 missing date cert mtn: height missing for revision 0e67b65edabb68ee96fe6d4eff5a32c3da79b013 mtn: warning: 2 unreferenced files mtn: warning: 2 incomplete revisions mtn: warning: 1 missing rosters mtn: warning: 445 missing certs mtn: warning: 40 mismatched certs mtn: warning: 1 missing heights mtn: check complete: 51774 files; 16115 rosters; 16116 revisions; 60 keys; 64807 certs; 16117 heights mtn: total problems detected: 491 (449 serious) mtn: error: serious problems detected $ (module missing and duplicated certs). For record: db kill_rev_locally on this revision helped issue and following pull retrieved it correctly. - Zbyszek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] [bug #29982] Windows installer does not install documentation CSS and images
Update of bug #29982 (project monotone): Assigned to:None = zzagorski Open/Closed:Open = Accepted ___ Reply to this item at: http://savannah.nongnu.org/bugs/?29982 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Release time
Hi, 2010/5/27 Jack Lloyd ll...@randombit.net I can think of a few things that might potentially happen that might be harder to pull off post-1.0: - s/netxx/asio/ AFAIR, it's only implementation detail. Do we wan't to change netsync protocol together with asio introduction ? - netsync over TLS It's a pure new feature that could be easy added over existing monotone functionality. Am i missing something ? - policy branches ... Giving that lot of us consider monotone as stable and production ready, policy branches (+nuskool sync maybe) will a revolution that fully justifies even 2.0 switch ... considering that we will decide to lock 1.0. BTW, a minor suggestion: if the next release is 1.0, perhaps this would be the time to switch the versioning scheme? 1.0 implies stability, so people will be surprised if there are major changes between, say, 1.23 and 1.24. Going to a triplet major.minor.patch ala Linux kernel would make it easier for users to see which were small or bugfix releases (1.0.4-1.0.5) and which were larger (1.0.5-1.1.0). +1. Summarizing, i fully agree that monotone is 1.0 ready - maybe not with very next release but soon. I mean that content is 99% complete for production use and only improvements are needed. -- Zbigniew Zagórski / software developer / geek / http://zbigg.blogspot.com / ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] [bug #29835] 'update -b' fails where 'update -r h:b' succeeds
Follow-up Comment #2, bug #29835 (project monotone): (slept with that problem and ... ) 1. forget current patch, it's broken in regards to error/empty branches handling. I am preparing one new. Second, more important issue is that this changes how update works. Current update worked in two modes: 1. with -r - updates to _anything_ 2. with branch (implicit or not) - updates only to descendants of current revision This patch changed update so it would work like this: 1. with -r - updates to _anything_ 2. with branch (implicit or not) updates to - descendants of current revision OR - any head of specified branch (if merged) (equivalent to -rh:branch) Question: do we want to unify this behaviour? ___ Reply to this item at: http://savannah.nongnu.org/bugs/?29835 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] [bug #28799] mtn pull hangs with invalid --keydir option
Update of bug #28799 (project monotone): Status:None = Fixed Open/Closed:Accepted = Closed ___ Follow-up Comment #6: committed revision 068f28e6a2b6d700daec031853de0b925cf415f6 (no test as this is only sporadic performance issue) ___ Reply to this item at: http://savannah.nongnu.org/bugs/?28799 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] [bug #15477] doesn't restore vt state if canceled with Ctrl+C
Update of bug #15477 (project monotone): Open/Closed:Open = Accepted ___ Follow-up Comment #2: Confirmed, 0.25 has didn't restore vt settings. --- $ ./monotone-0.25-linux-x86 -d foo.mtn genkey xxx monotone: generating key-pair 'xxx' enter passphrase for key ID [xxx]: monotone: interrupted |i686| zb...@home:/home/zbigg/projects/monotone/sandbox/0.25 $ -bash: foo: command not found --- On monotone 0.47/linux it restores vt settings correctly. --- |i686| zb...@home:/home/zbigg $ mtn genkey foo enter passphrase for key ID [foo] (...): mtn: operation canceled: Interrupt |i686| zb...@home:/home/zbigg $ aa -bash: aa: command not found |i686| zb...@home:/home/zbigg $ --- ___ Reply to this item at: http://savannah.nongnu.org/bugs/?15477 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] [bug #15477] doesn't restore vt state if canceled with Ctrl+C
Update of bug #15477 (project monotone): Severity: 3 - Normal = 2 - Minor Status:None = Fixed Open/Closed:Accepted = Closed ___ Reply to this item at: http://savannah.nongnu.org/bugs/?15477 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] [bug #18886] Crash if mtn genkey fails to save a key because of improper file system rights
Update of bug #18886 (project monotone): Severity: 3 - Normal = 2 - Minor Open/Closed:Open = Accepted ___ Reply to this item at: http://savannah.nongnu.org/bugs/?18886 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] [bug #18886] Crash if mtn genkey fails to save a key because of improper file system rights
Update of bug #18886 (project monotone): Status:None = Fixed Open/Closed:Accepted = Closed ___ Follow-up Comment #1: mtn 0.31: $ mv /home/zbigg/.monotone/ /home/zbigg/.monotoneX $ chmod -w ~ $ ./mtn-0.31-linux-x86 genkey spam mtn-0.31-linux-x86: generating key-pair 'spam' enter passphrase for key ID [spam]: confirm passphrase for key ID [spam]: mtn-0.31-linux-x86: storing key-pair 'spam' in /home/zbigg/.monotone/keys/ mtn-0.31-linux-x86: fatal: boost::filesystem::filesystem_error: boost::filesystem::create_directory: /home/zbigg/.monotone: Permission denied mtn-0.31-linux-x86: this is almost certainly a bug in monotone. mtn-0.31-linux-x86: please send this error message, the output of 'mtn-0.31-linux-x86 --full-version', mtn-0.31-linux-x86: and a description of what you were doing to monotone-de...@nongnu.org. mtn-0.31-linux-x86: failed to write debugging log to /home/zbigg/.monotone/dump mtn 0.47: |i686| zb...@home:/home/zbigg/projects/monotone/0.31 $ mtn genkey spam enter passphrase for key ID [spam] (...): confirm passphrase for key ID [spam] (...): mtn: generating key-pair 'spam' mtn: storing key-pair 'spam' in /home/zbigg/.monotone/keys/ mtn: error: could not create directory '/home/zbigg/.monotone': Permission denied ___ Reply to this item at: http://savannah.nongnu.org/bugs/?18886 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] [bug #28799] mtn pull hangs with invalid --keydir option
Update of bug #28799 (project monotone): Open/Closed:Open = Accepted ___ Follow-up Comment #1: Still in 0.47 Additional test: mtn --keydir $HOME ls keys also hangs in same place. Stacktrace is same: #0 0xb7b77350 in std::string::rfind () from /usr/lib/libstdc++.so.6 #1 0xb7b773c4 in std::string::rfind () from /usr/lib/libstdc++.so.6 #2 0x08201ef6 in read_packets (i...@0xbf91d08c, co...@0xbf91d154) at packet.cc:385 #3 0x081ed998 in key_store_state::maybe_read_key_dir (this=0x855f060) at key_store.cc:241 #4 0x081f3cc3 in key_store::get_key_ids (this=0xbf91d3a8, pr...@0xbf91d21c) at key_store.cc:248 # ___ Reply to this item at: http://savannah.nongnu.org/bugs/?28799 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] [bug #28799] mtn pull hangs with invalid --keydir option
Update of bug #28799 (project monotone): Category: networking = performance mtn version --full:mtn-0.46 = mtn-0.46, 0.47 ___ Follow-up Comment #3: Agree - This is not a hangup but monotone is just incredibly slow at reading big packets (is this only here?). (It just happened that I had big files in my home folder) -- $ ls -l /home/zbigg/bar/ total 984 -rw-r--r-- 1 zbigg zbigg 100 2010-04-29 14:08 one_megabyte_file $ time mtn --keydir /home/zbigg/bar ls keys mtn: no keys found real0m52.541s user0m52.450s sys 0m0.080s |i686| zb...@home:/home/zbigg/bar -- This is in read_packets(packets.cc) bug which tries to read packet in 255 byte chunks and suffers heavily with Shlemiel the painter's algorithm problem (constantly searches buffer for [end] string). Probably some Optimization is needed here. (Wandering if this doesn't affect overall monotone performance) ___ Reply to this item at: http://savannah.nongnu.org/bugs/?28799 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] [bug #28799] mtn pull hangs with invalid --keydir option
Update of bug #28799 (project monotone): Severity: 3 - Normal = 2 - Minor Assigned to:None = zzagorski ___ Follow-up Comment #4: Fix in attachment: 1. read_packets is fast O(n) when reading big files 2. monotone warns about bad keys files in key store (bad key files is one who has no packets inside). If no one objects i will commit this tommorow. (file #20376) ___ Additional Item Attachment: File name: fast_read_packets.patchSize:2 KB ___ Reply to this item at: http://savannah.nongnu.org/bugs/?28799 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] [bug #20898] Strange errors when out of disk space
Follow-up Comment #2, bug #20898 (project monotone): In 0.46, this is fixed. All following are executed on partition that is full: Update: $ mtn up mtn: warning: Failed to write options file _MTN/options: error: error writing to temp file _MTN/mtg0tgqj.tmp: No space left on device mtn: updating along branch 'pl.reddix.tinfra' mtn: already up to date at a432a415b6cd06cab651864a38849981ab321a70 mtn: warning: Failed to write options file _MTN/options: error: error writing to temp file _MTN/mt6x8348.tmp: No space left on device Status: $ mtn st mtn: warning: Failed to write options file _MTN/options: error: error writing to temp file _MTN/mtv5ywi1.tmp: No space left on device Current revision: 64ce1caec7c2f6c16f9839142c2c6c20745700f6 Current branch: pl.reddix.tinfra Changes against parent a432a415b6cd06cab651864a38849981ab321a70 no changes New database $ mtn -d foo.mtn db init mtn: error: sqlite error: database or disk is full ___ Reply to this item at: http://savannah.nongnu.org/bugs/?20898 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time for a release
Hi! 2010/3/8 Timothy Brownawell tbrow...@prjek.net empty_environment needs to copy in all the DLLs that the monotone executable uses. It has a hardcoded list, which I'm guessing isn't quite right for your environment. Do you know if Windows has a (non-gui) 'ldd' equivalent that we could use to get the list right? I've faced this problem last time and result is that the only known tool - depends.exe [1] has also CLI interface. It's a little awkward so i've made simple wrapper [2] that makes readable ldd greppable output. [1] http://www.dependencywalker.com/ [2] http://pastebin.com/wxreDxFu Regards! -- Zbigniew Zagórski / software developer / geek / http://zbigg.blogspot.com / ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] fatal: memory access violation running mtn log
Hi! Danny MacMillan pisze: Hi, I just got an error using monotone. What I did was basically follow the cut Revision: 045b0286268ed071e6ac83bc87cdcb751b38718f cut C:\Program Files\monotone\mtn.exe: fatal: memory access violation this is almost certainly a bug in monotone. please send this error message, the output of 'C:\Program Files\monotone\mtn.exe version --full', and a description of what you were doing to monotone-devel@nongnu.org cut Thanks for report! This error is reproducible on other machines. I am analyzing the cause. Failing test case (on nvm workspace): mtn log --from 045b0286268ed071e6ac83bc87cdcb751b38718f fails also here, but in somewhat different place (maybe it's a buffering problem?): | o - | | Revision: 8313738ccc7884cf79fb1b3b66fe418f61b1e07a | | Ancestor: 184259296d94033bb62d0775bb0288efefe917d1 | | Author: Richard Levitte rich...@levitte.org | | Date: 2009-01-15 14:45:31 | | Branch: net.venge.monotone | | | | Modified files: | | contrib/display_branches.lua | | | | ChangeLog: | | | | * contrib/display_branches.lua: Modernised version. Program received signal SIGSEGV, Segmentation fault. And for the rest - here is the backtrace: 0x007d120e in date_t::as_formatted_localtime (this=0x22ea48, f...@0x22f6d0) at ../net.venge.monotone/dates.cc:367 367 tm tb(*std::localtime(t)); (gdb) bt #0 0x007d120e in date_t::as_formatted_localtime (this=0x22ea48, f...@0x22f6d0) at ../net.venge.monotone/dates.cc:367 #1 0x004d6525 in log_date_certs (cer...@0x22f0e0, o...@0x22f000, f...@0x22f6d0, label=0xc41c4e Date: , separator=0xc41c4e Date: , multiline=false, newline=true) at ../net.venge.monotone/vocab_terms.hh:618 #2 0x004e158a in commands::cmd_log::exec (this=0xcd17a0, a...@0x22fb10, exec...@0x22fad0, ar...@0x22fb10) at ../net.venge.monotone/cmd_diff_log.cc:697 #3 0x00476a9b in commands::process (a...@0x22fb10, ide...@0x22fad0, ar...@0x22fb10) at ../net.venge.monotone/cmd.cc:118 #4 0x0080e195 in cpp_main (argc=4, argv=0x3e4a68) at ../net.venge.monotone/monotone.cc:285 #5 0x0080ea1b in main (argc=4, argv=0x3e4a68) at ../net.venge.monotone/win32/main.cc:198 (gdb) Best regards! -- Zbigniew Zagórski / software developer / geek / http://zbigg.blogspot.com / ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] fatal: memory access violation running mtn log
Hello! Zbigniew Zagórski wrote: Hi! Danny MacMillan pisze: Hi, I just got an error using monotone. What I did was basically follow the cut Revision: 045b0286268ed071e6ac83bc87cdcb751b38718f cut C:\Program Files\monotone\mtn.exe: fatal: memory access violation this is almost certainly a bug in monotone. please send this error message, the output of 'C:\Program Files\monotone\mtn.exe version --full', and a description of what you were doing to monotone-devel@nongnu.org cut Thanks for report! This error is reproducible on other machines. I am analyzing the cause. Failing test case (on nvm workspace): mtn log --from 045b0286268ed071e6ac83bc87cdcb751b38718f fails also here, but in somewhat different place (maybe it's a buffering problem?): Hello! OK, problem identified. Someone/somewhere had misconfigured machine (?) and thus generated weird date cert: $ mtn ls certs cdf1680ec496d22f863184a cut Key : tbrow...@gmail.com (475055ec71...) Sig : ok Name : date Value : 1969-12-25T17:04:08 ^^^ and looks like localtime on woe32 can't cope with this - thus returning 0 from localtime call. Recap: failing test case: $ mtn log --from cdf1680ec496d22f863184a --last 1 -- Zbigniew Zagórski / software developer / geek / http://zbigg.blogspot.com / ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] monotone 0.46 has been released
Hello! 2010/1/17 Thomas Keller m...@thomaskeller.biz: The monotone developers are proud to announce the release of version 0.46. The highlights in this release are bisection support - thanks to ... Thanks for your effort! Thanks again to everybody who made this release possible! Grab it while its hot ;) Win32 native is availalbe at download page. Everything works fine besides of few failed test cases - AFAIR all of them are good old known issues: 89 automate_lua FAIL (line 51) 0:06 100 automate_show_conflicts FAIL (line 266) 2:22 133 checkout_in_windows_root FAIL (line 11) 0:05 161 date_formatting FAIL (line 26) 0:10 210 empty_environment FAIL (line -1) 0:03 -- Zbigniew Zagórski / software developer / geek / http://zbigg.blogspot.com / ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] adding existing pubkey - incorrect invariant
Hello,
Looks like we've got some small issue. You can't add pubkey to db/keystore when
it is already known.
It's minor but shall not be internal invariant as it is now. IMHO, mtn
read shall ignore
packets that contain already known information and here we have exception (and
it ignores in all other cases)
(BTW, when importing privkey everything works perfectly)
Offending code:
database::put_key(key_name const pub_id,
rsa_pub_key const pub)
{
//(...)
I(!public_key_exists(thash)); // BAD! to be removed
if (public_key_exists(thash)) // never executed
{
L(FL(skipping existing public key %s) % pub_id); // maybe
shall be removed also
return false;
}
Test case using my pub key:
$ mtn ls keys | grep zbigg
3c5bcd300193a6b8e9a39a2fbf8185e2fa6942e1 zb...@zbigg.org
$ cat zb...@zbigg.org
[pubkey zb...@zbigg.org]
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7ixlgafREiQMbrpF8EUqm0BwmVycQhFlt
YVx6YFByXUkGI8mdvghKxxatr2xuD+KQdfZzuNKN2AWDBBu8qMj1scEbeqttGx05VDU6kw/r
STb6U8PA2difOMxq1aoi/V4lUBBouav0gZG8IKefIgCblLs2lNQvH9+rWZ/hZiQEawIDAQAB
[end]
$ mtn read zb...@zbigg.org
mtn: fatal: error: database.cc:3078: I(!public_key_exists(thash))
...
Monotone version: 0.45
OS: win32/linux
Best regards!
--
Zbigniew Zagórski
/ software developer / geek / http://zbigg.blogspot.com /
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [ANN] monotone 0.43 released
2009/3/26 Phil Hannent p...@hannent.co.uk: Zack Weinberg wrote: Your compiler is probably pickier about the headers; try adding #include iterator and/or #include algorithm to the top of the file. First off, thanks for your help. It is appreciated. I have just been trying to progress this a little more, I am getting the following error: Error 749 error C2057: expected constant expression c:\buildbot\monotone-0.43.tar\monotone-0.43\mkstemp.cc 141 tester ... Error 147 error C3416: 'dump' : an explicit specialization may not be explicitly instantiated c:\buildbot\monotone-0.43.tar\monotone-0.43\vocab.cc 190 tester ... Any help would be appreciated. Hello, What version of g++ are you using. Looks like 4.3 ... monotone is uncompilable with newer 4.3 gcc. Unfortunately. Please try with 3.4.5 - the official version provided by mingw. -- Zbigniew Zagórski / software developer / geek / http://zbigg.blogspot.com / ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [ANN] monotone 0.43 released
2009/3/23 Thomas Keller m...@thomaskeller.biz: Hi fellows! A new version was released today with these changes: * monotone no longer bundles several required 3rd party libraries; this not only makes our life easier but was often requested by distributions. * monotone can now be configured to use forward deltas which speeds netsync servers quite a lot. * the speed of mtn log has been improved tremendously and new useful selectors became available there. * monotone can now export its databases into git's fast-import format (hey, but that doesn't mean you guys should now all switch to git ;) * tons of bugfixes... Good news. Thanks, and keep up good work. One note from me: last few versions i've builduploaded win32 installers. Now i'm out of time and resources so I don't know when i will find spare time to build win32 version. Please anyone take note of this and buildupload win32 installer. Best regards, -- Zbigniew Zagórski / software developer / geek / http://zbigg.blogspot.com / ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] automate get_current_revision failing
2009/3/9 Thomas Moschny thomas.mosc...@gmx.de: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi! Zbigniew Zagórski wrote: 2009/3/7 Thomas Moschny thomas.mosc...@gmx.de: In f62181ae.. someone made mtn automate get_current_revision fail in Apologies, it was me :/ Just curious: What was the idea/intention behind it? Memory is short, sorry. This change was intentional. See the thread: http://thread.gmane.org/gmane.comp.version-control.monotone.devel/13632/focus=13872 According to this discussion revision can't be empty ... because it doesn't make sense. I have to think a little about this ... Regards, -- Zbigniew Zagórski / software developer / geek / http://zbigg.blogspot.com / ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Fwd: [Monotone-devel] automate get_current_revision failing
Hello, 2009/3/7 Thomas Moschny thomas.mosc...@gmx.de: In f62181ae.. someone made mtn automate get_current_revision fail in Apologies, it was me :/ case the workspace is clean, and the revision is trivial (empty changeset). I don't see why this should fail, and furthermore, it breaks the logic that makes mtn revision --full display changes made against the base revision. So, I'd like to partially revert that (see patched attached). Any objections? Absolutely no. It was stupid mistake. Strange that spotting this took a whole year ... Please fix it as i don't have any workable monotone build site (landing of ...stripped has complicated build ...) -- Zbigniew Zagórski / software developer / geek / http://zbigg.blogspot.com / -- Zbigniew Zagórski / software developer / geek / http://zbigg.blogspot.com / ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] nvm.fast-export
2009/3/5 Derek Scherger de...@echologic.com: If there aren't any objections I think I'm ready to land the fast-export branch (the new git_export command) but I'll wait until this weekend before I do. This branch doesn't change any existing functionality so there should be no risk of breaking anything. I've exported and successfully imported a monotone database, a pidgin database, an older open embedded database and a xaraya database so at the very least it does produce things that git fast-import can handle. I've also done some verifications on each of these by checking out each branch and tag that can be checked out (by a dumb script) and diffing the results and I haven't found any problems so far. Hi, Just for curiosity. NEWS file on branch says: - A monotone database may be exported in the git fast-import format using the git_export command. The output from this command may be piped into git fast-import or other tools supporting this format. I haven't followed thread related to this topic. Does this feature supports incremental export ? Namely export only things that are not in git repo yet ? Best regards, -- Zbigniew Zagórski / software developer / geek / http://zbigg.blogspot.com / ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Question for Windows automate users
2009/2/22 Timothy Brownawell tbrow...@prjek.net:
On Sun, 2009-02-15 at 10:27 -0800, Zack Weinberg wrote:
What's the intended effect of the make_io_binary() call in
automate::exec()? It looks like we're setting stdin and stdout to
binary mode for any automate operation, but that doesn't seem right --
if you're just running one automate command inside a batch file or
something you'd want DOS line endings, wouldn't you?
get_file / get_file_of and put_file need to be binary-safe, so they work
with binary files. stdio needs to be binary-safe, so the byte counts
don't get messed up.
The others probably don't care, but making them not binary (1) would be
inconsistent, and (2) would mean that they'd give slightly different
output when run through stdio. Not sure how much these points actually
matter, especially for the commands that generate lists (tags,
ancestors, inventory) rather than dumping items (get_current_revision).
Agree in general. Summarizing:
1. Automate stdio must be always binary safe and consistent amongst platforms.
Imagine automate client working on windows reading from some ssh-ed
process on some unix (or vice versa). How one can know if that remote
one is unix/windows?
2. Standalone command execution:
For first-class data (revision text, cert value, file content, diff)
value it MUST be binary safe.
Invocation of:
monotone au get_revision RID | sha1sum
must print RID regardless of platform and shell (that's also problem
with sha1sum tool which must read in binary mode but we have to make
monotone work as expected in this scenario).
Synthetic, query like data it can have native line-end so it can be
successfully parsed using platform shell utils (btw are there any
_other than unix-like_ shell text tools on any platform?). I think it
covers any revision list, tags, keys, inventory, graph, options,
attibutes (really? **).
Packet IO is already line-ending agnostic and base64 meaning doesn't
change regardless of LE sequence. Native line-ending can be used.
Perhaps default to binary for stdio and maybe get_file(_of)/put_file (or
maybe not, since most files will probably be text files) and text for
the others, with a --binary={yes|no} option to override this?
Not good idea IMHO. If there should be any option here it should be
monotone-wide and be something like --line-ending={native,CR,LF, CRLF}
(or unix,windows,mac). But that's pandora box we don't want open. It
was discussed several times without any reasonable result other than
it's a minefield.
**Hmmm.
Attribute value is part of revision text and i bet it can include
newline inside. So it's value should also be LE-consistent.
Regards,
ZZ
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] memory access violation in win32 0.42 when canceling blocked `mtn diff --external` using Ctrl+C
Hi all, 2009/1/7 Markus Wanner mar...@bluegap.ch: ... Thanks for your report. Did you (or anybody else on MinGW) run the test suite for 0.42? Yep, i've ran test suite before publishing binaries. There were no ... err, almost no failures. At least no significant ones. Failures: util_mtnopt because windows doesn't have /bin/sh usually installed automate_lua because 3.4 on polish locale is 3,4 grrr They are: 1. minor, 2. unrelated I forgot to report them never mind having time to fix. Best regards, Zbyszek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] memory access violation in win32 0.42 when canceling blocked `mtn diff --external` using Ctrl+C
Hi, 2009/1/7 Markus Wanner mar...@bluegap.ch: ... Can you reproduce what the OP reported? Unfortunately no (and yes ... see the end) In fact mtn diff --external doesn't work OOB because it tries to pass arguments to execute in wrong way or lua execute is broken on win32. Nevertheless lua execute doesn't quote strings with tabs. I can't find definition of lua execute to confirm this. When I fixed this the only thing i've got after doing CTRL+C while kdiff3 was running was: mtn: botan_pipe_cache.hh:41: invariant 'I(!pipe)' violated mtn: saving current work set: 4 items in debug log. And all of this was using msys shell. But at some time while writing this post i realized that windowz has also native shell, so .. When using cmd as shell I can reproduce the bug and it appears to be very strange. I use kdiff3 as external diff tool - just for example. Test: - goto to workspace with 2 modified files 1. execute mtn diff --external (kdiff3 is spawned) 2. CTRL+C on terminal (kdiff3 lives and ... monotone still lives and ...) (at this time crash dump is printed to debug log) (second kdiff3 is spawned for next file) 3. Next CTRL+C on terminal (no next kdiffs are spawned) 4. Close any of kdiff (next kdiff is spawned) 5 Close all kdiffs (monotone finally crashes - reports fatal: memory access violation... and process ends) [debug log for session attached] Well this is strange ... and confirms how badly process control is messed up on w32. Daniel, you must have custom external_diff hook, could you send it together with output of failed monotone execution with --debug flag ? What shell do you use ? Do you confirm this kind of strange monotone behaviour or you have clean crash CTRL+C === monotone crash ? Best regards, -- Zbigniew Zagórski / software developer / geek / happy daddy / Debug log of execution mtn diff --external --debug ... cut, unrelevant, lost log mtn: selected node 2204 guarded_map.h parent 1685 mtn: adding node 2204 guarded_map.h parent 1685 mtn: selected node 2205 guarded_test.cpp parent 1685 mtn: adding node 2205 guarded_test.cpp parent 1685 # # old_revision [fdce1ddd89744e27d98d6f76ed6bd24261f79fea] # # patch guarded_test.cpp # from [6190488ef71339e1465a4293b0d5cae2d16f01c0] #to [adc83b19e793491b1c6ea0fd8b46cd9f32e592fc] # # patch http_server.cpp # from [09001b30346fccab467ba306972e7ee974d6c4a6] #to [adc83b19e793491b1c6ea0fd8b46cd9f32e592fc] # # patch list_files_generator.cpp # from [3fcaa778d753a132cdcb9294d7c2e1b9115eff17] #to [adc83b19e793491b1c6ea0fd8b46cd9f32e592fc] # # patch posix_signals.cpp # from [93b66589ab1d8c8ec6f089509503ea9cbf9abe29] mtn: prepared statement SELECT 1 FROM files WHERE id = ? LIMIT 1 mtn: binding 1 parameters for SELECT 1 FROM files WHERE id = ? LIMIT 1 mtn: binding 1 with value '6190488ef71339e1465a4293b0d5cae2d16f01c0' mtn: prepared statement SELECT data FROM files WHERE id = ? mtn: binding 1 parameters for SELECT data FROM files WHERE id = ? mtn: binding 1 with value '6190488ef71339e1465a4293b0d5cae2d16f01c0' mtn: loading lua hook external_diff mtn: searching for exe: kdiff3 mtn: spawning command: 'c:\programs\kdiff3\kdiff3.exe' 'kdiff3 -u -L1 guarded_test.cpp old C:\DOCUME~1\zagorski\LOCALS~1\Temp/mtn.V3QLTQ -L2 guarded_test.cpp new C:\DOCUME~1\zagorski\LOCALS~1\Temp/mtn.PEROA6 ' #to [adc83b19e793491b1c6ea0fd8b46cd9f32e592fc] # # patch tickedit/tickedit.cpp # from [f1d085e6d55543ce948ecfda1db7dda32ff6d0b9] #to [b525ce7ae4ee15e38cfd624d91323790e9bc9814] # COMMENT: CTRL+C here mtn: botan_pipe_cache.hh:41: invariant 'I(!pipe)' violated mtn: saving current work set: 4 items mtn: finished saving work set mtn: contents of work set: mtn: Current work set: 4 items mtn: - begin 'system_flavour' (in virtual void sanity::initialize(int, char**, const char*), at sanity.cc:75) mtn: Windows NT/2000/XP/2003 (5.1, build 2600, Service Pack 2) on ia32 (level 15, rev 1025) mtn: - end 'system_flavour' (in virtual void sanity::initialize(int, char**, const char*), at sanity.cc:75) mtn: - begin 'cmdline_string' (in virtual void sanity::initialize(int, char**, const char*), at sanity.cc:89) mtn: 'mtn', 'diff', '--external', '--debug' mtn: - end 'cmdline_string' (in virtual void sanity::initialize(int, char**, const char*), at sanity.cc:89) mtn: - begin 'string(lc_all)' (in virtual void sanity::initialize(int, char**, const char*), at sanity.cc:94) mtn: Polish_Poland.1250 mtn: - end 'string(lc_all)' (in virtual void sanity::initialize(int, char**, const char*), at sanity.cc:94) mtn: - begin 'full_version_string' (in virtual void mtn_sanity::initialize(int, char**, const char*), at mtn-sanity.cc:23) mtn: monotone 0.42 (base revision: 75ac12dd5b02025981edd6cd03caebb54721e481) mtn: Running on : Windows NT/2000/XP/2003 (5.1, build 2600, Service Pack 2) on ia32 (level 15, rev 1025) mtn: C++ compiler: GNU C++ version 3.4.5 (mingw special) mtn: C++ standard
Re: [Monotone-devel] [ANNOUNCE] monotone 0.42 released
Hi all, 2008/12/27 Thomas Keller m...@thomaskeller.biz: I have released monotone 0.42 today. Thanks!!! ... As usual, monotone can be downloaded from http://monotone.ca Binary files are posted there as they come in. Win32 binary available here: http://monotone.ca/downloads/0.42/monotone-0.42-setup.exe PS. I can't update main page download link ... Stupid thing - I can't checkout net.venge.monotone.web branch on win32 because of colons in file names (some wiki pages). So link do download will appear as soon as i reach some machine with posix filesystem. Happy New Year! -- Zbigniew Zagórski / software developer / geek / happy daddy / ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] mtndumb public cert_id
Hello,
I'm slowly hacking monotone dumb transport for my personal
use (i don't have time to polish it to publishable state)
and found that it's very slow in creating merkle tree of
revisions and certs. It's because there is no access to
cert_id (it's SHA1 of all cert values joined with colon).
For dumb protocol and any other tool that could simulate
monotone server it's a must to have possibility to query for:
- packet of specific cert
- ids of certificates for given selector (or only revision)
Currently cert packet api provids only get all cert packets
of revision. It's usually redundant information because we
usually need only cert_id and packet is needed only if
algrorithm decides that it's to be transfered.
So my proposition is to add new public entity 'cert_id' and
commands to retrieve it. For sake of simplicity it will be the
same as database cert_id (hash field of revision_certs table).
Automate commands:
get_packet_for_cert CERTID
Get single packet for cert with given certificate id.
select_certs SELECTOR
Get certs identifiers for revisions specified by SELECTOR.
Each output line contains pair REVID,CERTID separated by one
space character.
That would render mtndumb as fast as netsync when it comes
to build merkle tree. I bet it would be usable also for databases
as big as monotone.ca. Only difference would be transport.
Question:
Any objections for adding these kind of commands ?
[_Draft_ of implementation attached]
PS1. I know about nuskool effort but i also realize that it's
still lot to be done to make it work so i think that mtndumb
is really feasible tool for small personal projects.
Currently it works reasonably well with database of size ~12MB
(1200 revisions) i know it's not much but it's something.
PS2. Anybody uses mtndumb ?
PS3. Monotone dumb is file/sftp/ftp/http* transport for synchronizing
montone database.
Best regards,
--
Zbigniew Zagórski
/ software developer / geek / happy daddy /
#
# old_revision [9b264ec9247ce99cd1fdc5293e869c1a60b01c4c]
#
# patch automate.cc
# from [9a700bfc52a6a21e3b5d2d930ad634d455dafcae]
#to [1ca44a73bf87274762a68c436f3b6b628b94d4aa]
#
--- automate.cc 9a700bfc52a6a21e3b5d2d930ad634d455dafcae
+++ automate.cc 1ca44a73bf87274762a68c436f3b6b628b94d4aa
@@ -517,6 +517,41 @@ CMD_AUTOMATE(select, N_(SELECTOR),
output *i '\n';
}
+// Name: select_cert
+// Arguments:
+// 1: selector
+// Added in: 8.1
+// Purpose: Prints all the certs for revisions that match the given selector.
+// Output format: A list of pairs [cert_id, revision_id], both in hexadecimal, each followed by a
+// newline. There is no particular order of values.
+// Error conditions: None.
+CMD_AUTOMATE(select_cert, N_(SELECTOR),
+ N_(Lists certs for revisions that match a selector),
+ ,
+ options::opts::none)
+{
+ N(args.size() == 1,
+F(wrong argument count));
+
+ database db(app);
+ project_t project(db);
+ setrevision_id completions;
+ expand_selector(app.opts, app.lua, project, idx(args, 0)(), completions);
+
+
+ for (setrevision_id::const_iterator i = completions.begin();
+ i != completions.end(); ++i)
+ {
+std::vectorid cert_ids;
+project.get_revision_cert_hashes(*i, cert_ids);
+for(std::vectorid::const_iterator ii = cert_ids.begin();
+ii != cert_ids.end(); ++ii )
+{
+output *i ' ' *ii '\n';
+}
+ }
+}
+
struct node_info
{
bool exists;
@@ -1499,6 +1534,37 @@ CMD_AUTOMATE(packets_for_certs, N_(REVI
pw.consume_revision_cert(*i);
}
+// Name: packet_for_cert
+// Arguments:
+// 1: a cert id
+// Added in: 8.1
+// Purpose: Prints the cert associated/
+//
+// Output format: certs in monotone read compatible packet format
+//
+// Error conditions: If the cert id specified is unknown or
+// invalid prints an error message to stderr and exits with status 1.
+CMD_AUTOMATE(packet_for_cert, N_(CERTID),
+ N_(Prints the certs in packet format),
+ ,
+ options::opts::none)
+{
+ N(args.size() == 1,
+F(wrong argument count));
+
+ database db(app);
+ //project_t project(db);
+ packet_writer pw(output);
+
+ id c_id(decode_hexenc(idx(args, 0)()));
+ revisioncert cert;
+
+ //N(db.cert_exists(c_id), F(no such cert '%s') % c_id);
+ db.get_revision_cert(c_id, cert);
+
+ pw.consume_revision_cert(cert);
+}
+
// Name: packet_for_fdata
// Arguments:
// 1: a file id
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] mtndumb public cert_id
2008/12/17 Thomas Keller m...@thomaskeller.biz: Zbigniew Zagórski schrieb: Hello, I'm slowly hacking monotone dumb transport for my personal use (i don't have time to polish it to publishable state) and found that it's very slow in creating merkle tree of revisions and certs. It's because there is no access to cert_id (it's SHA1 of all cert values joined with colon). For dumb protocol and any other tool that could simulate monotone server it's a must to have possibility to query for: - packet of specific cert - ids of certificates for given selector (or only revision) Currently cert packet api provids only get all cert packets of revision. It's usually redundant information because we usually need only cert_id and packet is needed only if algrorithm decides that it's to be transfered. So my proposition is to add new public entity 'cert_id' and commands to retrieve it. For sake of simplicity it will be the same as database cert_id (hash field of revision_certs table). I never dived much into the merkle tree thing, ...but if I understand you correctly this needs the signature / sha1 of a single cert in order to determine if it needs to be send over the wire or not, right? Yes. Synchronization by merkle trees works in two phases: - find-the-difference - to the sync only missing/extra elements All i'm talking is the first step. Finding differences. In first step you must collect all ids (revision ids, cert ids, key ids) that exist in database (let's say L). Remote tree set built from remote site (lat's call it R). - pushing you have to push elements from set L-R to remote. - when pulling you have to retrieve elements from set R-L And regarding pushing, actual data is retrieved and serialized only for pushed set and not for all certs. And you're basically looking for something which is faster than packets_for_certs REVID which only takes revisions, but not selectors, and which outputs more things than you actually need, correct? No in fact i look for get all certs and give me specific cert ... While adding new commands for this sounds reasonable at a first glance (100% backwards compatible with any automation implementation), I wonder if it wouldn't be better to just hack packets_for_certs (in a backwards-compatible way) f.e. by changing its first parameter, the revision ID, to a selector. Now you then still get all cert packets in return, not just the IDs which you need for the merkle tree, but is this really such a huge speed penalty? Well after thinking a little bit i need to clarify. The biggest penalty is cost of thousands of automate calls. It's rather big when it comes tho thousands (or tens of thousands) invocations. And it's kind of waste when you _always_ want all and only id, but not the packet. [BTW mtndumb is quite stupid, so it synchronizes whole database, so there is no point for restricting cert set or revision set. ] Regarding timing: For my private database (~1200 revs): old approach 15s(~1200 automate calls) new approach 2s (~15 automate calls) For net.venge.monotone db (14348 revs): old approach 180s (~14400 automate calls) new approach 10s(~70 automate calls) These are _very_ manual tests and take into account whole process running, including spawning python, monotone. BTW, on linux timings are usually twice as faster for old approach so win32 is also an issue. All i want is to have ~constant number of automate calls that return me bulk data from which i can safely build merkle tree. With old approach i need 2+N calls (two to get revisions and toposort them, N to get all certs for each revision). With new i have 3 calls (all revs, toposort, all certs). [Ah also there are keys, but it's minor issue] BTW, that's the whole problem with merkle tree: you must get _all_ _ids_ of entities in order to start synchronization. This is same with netsync and this is why nuskool has emerged. -- Zbigniew Zagórski / software developer / geek / happy daddy / ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Monotone Mini Summit: 2009-01-18 - 2009-01-19
2008/12/17 Philipp Gröschler monot...@plasma.cx: Thomas Moschny schrob: You could enhance/revive/polish/hack on the eclipse monotone plugin, if you like. That also was my idea back then. I had contact with a guy who wanted to cede his old codebase to me. In spite of some mails to him I never heard of him again. Well, have you contacted me? The very last minor improvements were by me ... Apparently, nothing interesting went from this plugin is in very beta state. For current status look at sources or to mailing list archives: - mtsh.mtn-host.prjek.net or ensued.net (netsync servers) - mailing list: http://news.gmane.org/gmane.comp.ide.eclipse.mtteam.devel/cutoff=173 -- Zbigniew Zagórski / software developer / geek / happy daddy / ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] mtndumb public cert_id
2008/12/17 Thomas Keller m...@thomaskeller.biz: Zbigniew Zagórski schrieb:... And you're basically looking for something which is faster than packets_for_certs REVID which only takes revisions, but not selectors, and which outputs more things than you actually need, correct? No in fact i look for get all certs and give me specific cert ... So, you're actually triggering `mtn automate select_cert '*'` then, right? Only because get all at once strategy won with get it when it's needed with speed. My original design was: foreach REV: certs = automate.select_certs(REV) for each cert: ... But it was replaced with greedy get into multimap, and then later use only map. It's always like that that pretty and simple design must be messed up because of performance issues. ... revision ID, to a selector. Now you then still get all cert packets in return, not just the IDs which you need for the merkle tree, but is this really such a huge speed penalty? Well after thinking a little bit i need to clarify. The biggest penalty is cost of thousands of automate calls. It's rather big when it comes tho thousands (or tens of thousands) invocations. And it's kind of waste when you _always_ want all and only id, but not the packet. This should have been gotten better a bit in 0.42 since Timothy fixed an issue with stdio which could not reuse the opened database instance for every call. I didn't checked it against trunk, but thanks for pointing this out: i'll check. ... Regarding timing: For my private database (~1200 revs): old approach 15s(~1200 automate calls) new approach 2s (~15 automate calls) For net.venge.monotone db (14348 revs): old approach 180s (~14400 automate calls) new approach 10s(~70 automate calls) ... Wow, ouch, but you're using automate stdio, right? Yes, I'm always politically correct. ;) [Do you imagine it possible to make 14000 process invocations in 180 s on win32? ;) ] All i want is to have ~constant number of automate calls that return me bulk data from which i can safely build merkle tree. With old approach i need 2+N calls (two to get revisions and toposort them, N to get all certs for each revision). With new i have 3 calls (all revs, toposort, all certs). Understood. I've just asked here a bit more because I think what you (and maybe others) are really looking for is an sql-like interface to some of the internal data structures. Sure, one could use the 'unstable' mtn execute interface, but I wonder if we should wrap something around this and provide access to the mtn internals for exactly these high-performance use cases. Well. I could happily use mtn db execute to get all certs. No problem for me (not that i would be proud of it ;) ... However i don't have good replacement for 'get_cert_for_packet CERTID'. No one sane in mind would want to duplicate packet generation in client side - that's real implementation detail. Namely the change was needed so i decided, why not make two good changes at once and win with need to use db execute. That's way select_certs emerged. It's design is not well thought, it's just something that was easiest to write with current infra and my sparse orientation in it. Other than that I'm ok with your patch if you add some documentation and tests to them. Of course i wanted do to th that way. If you like to see this in 0.42 you probably have to do this until the end of this week, otherwise it'll go into 0.43. In fact i've got this change sitting in one of my view for about a month or so and i've delurked out is because next release. I would like to see it there ... Nevertheless, I don't know if i'll manage (esp. about doctest part) so don't wait it's trivial. -- Zbigniew Zagórski / software developer / geek / happy daddy / ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] using monotone for a simple logging database
2008/11/29 John Wright [EMAIL PROTECTED]: (...) Unlike a DVCS my schema is flat, there is no notion of a tree of edits/commits, just a running straight history of logs. Actually there are no file blobs, just the log part of a commit. I am hoping that this can means I can implement this dvcs -lite logging repository in Javascript, Objective C, and Ruby without having to resort to anything but SHA1, basic language primitives and http and things available in most programming languages. I am writing you Monotone guys hoping somebody can help point me the relevant bits of Monotone that I can look at for inspiriation. (...) You're probably asking for merkle/hash tree based synchronization of sets. That's how monotone does it right now. There is simpler (and easier that netsync) Python implementation of it on net.venge.monotone.dumb branch. After throwing monotone hooks it should be able to synchronize anything that has unique signature (it doesn't have to be SHA1) and serializable to bytes. So ... anything. -- Zbigniew Zagórski / software developer / geek / happy daddy / ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] library build
2008/10/2 Jack Lloyd [EMAIL PROTECTED]: On Wed, Oct 01, 2008 at 07:34:20PM +0200, Markus Wanner wrote: After just having upgraded (and now landed) monotone's included botan to 1.7.12. Jack is already approaching 1.7.15 with yet another set of renaming. I'm rather going to use the nvm.stripped branch than continue to manually upgrade again. So if Botan 1.7.x is going to distros (AFAIK the only distro it is currently in is Debian) I would just as soon it be the future 1.7.15 rather than .14 since there are another slew of changes (in... BTW, 1.7.15 has minor change of API that makes some things ugly in monotone if we want to use system provided libraries. In lookup.h there are few get_cipher functions than in 1.7.14 and earlier versions where independent of Library_State and in 1.7.15 they require LibraryState as first parameter. *** It's not big deal for monotone to change to this new interface but _if_ we want use bundled system libraries that for some reason may be older than 1.7.15 we would need some #ifdefs and wrappers in monotone code. I don't question your design decisions but LibraryState is currently a singleton obtained via (AFAIR) Botan::get_default() so i don't see any reason for removing Botan::get_cipher overloads without LibraryState (correct me if I'm wrong). Old overloads can be marked as deprecated but it is wise to leave them for a while because current code base uses them. If it's part of bigger design, ,than we'll just write some wrapper functions with #ifdefs. *** New get_cipher: BOTAN_DLL Keyed_Filter* get_cipher(Library_State, const std::string, ...); Old get_cipher: BOTAN_DLL Keyed_Filter* get_cipher(const std::string, ...); Best regards, -- Zbigniew Zagórski / software developer / geek / happy daddy / ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] library build
2008/9/29 Jack Lloyd [EMAIL PROTECTED]: On Mon, Sep 29, 2008 at 12:01:50PM +0200, Zbigniew Zag??rski wrote: Jack: are you interested in making botan compliant to standard configure/make scenario ? Um not particularly, TBH. I really really do not like autoconf. And it is completely useless off Unix. Have very similar feelings. However most liked feature for me is ability automagically detect cross-compiling environment. That said if someone sent me a configure.in that worked and handled the same things configure.pl does I would certainly ship it at least as an option. I know it's overkill sometimes but making configuration script names configure and supporting --prefix option would be very convienient for some ad-hoc builders. Sorry I was misguided by fact that Makefile contained hardocoded C:\Botan ... i didn't notice that it was generated. Just it being named configure instead of configure.pl is a major factor? :( No, i was struggling with --os --cpu for a moment (wanting to build asm versions) but now everything is fine. BTW, I've got patch that enables configure.pl to detect mingw/msys automagically. -- Zbigniew Zagórski / software developer / geek / happy daddy / ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] library build
2008/9/28 Zbigniew Zagórski [EMAIL PROTECTED]: 2008/9/28 Stephen Leake [EMAIL PROTECTED]: ... MinGW doesn't have a decent package manager, and I don't know where to get pcre for MinGW; I looked for that a while ago. I haven't looked for the others. AFAIR, on properly configured mingw+msys ./configure --prefix=/mingw make install works like a charm for pcre-7.7. However, i don't know if botan sqlite builds natively on mingw32 without tricks. I'll try to pefrorm some research on topic. From my recent tests it appears that: - lua - pcre - botan - sqlite3 build without any problem on mingw/msys with simple ./configure --prefix=/mingw ; make ; make install However, lua and botan need some custom configuration and makefile invocation. I failed to build libidn on mingw and gave up after some strange libtool+DLL linking errors. Jack: are you interested in making botan compliant to standard configure/make scenario ? I know it's overkill sometimes but making configuration script names configure and supporting --prefix option would be very convienient for some ad-hoc builders. PS. I would like to test this library-build branch on mingw, is it buildable at least on some common platform like linux ? -- Zbigniew Zagórski / software developer / geek / happy daddy / ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [RFC] move unversioned files out of the way
2008/9/21 Thomas Keller [EMAIL PROTECTED]: Hi all! A annoyance for me has always been that monotone can't switch to another workspace if it has to remove directories which are not present in the target revision and these directories contain unversioned files (f.e. editor backup files). monotone then bails out with X workspace conflicts and lets the user clean up his mess. Random idea related to topic: Maybe monotone could delete ignorable files/folders? This would solve your problem in more pragmatic way - no other options needed, just correct .mtn-ignore file. Current behaviour is just strict implementation of no data loss paradigm. Question is: Are ignorable files the same as not important? If yes monotone can delete them. I don't know the answer, for me it's almost yes. In my projects ignorable files are always generated, backup or temporary. How is this in other projects ? Community must decide which behaviour is most expected. So I hacked something together last week or so, for which I want to get some feedback. The code resides in nvm.experiment.remove_leftover_files and essentially does the following: It introduces a new option --move-conflicting-paths for all workspace-update related commands (clone, checkout, update, merge_into_workspace) which then notices conflicting paths during the simulated working tree phase and moves these conflicting paths into _MTN/conflicts/DATETIME, where DATETIME is the current date/time stamp of the update operation. ... If answer to above is no then it's the only reasonable solution. BTW. This command is *reliable version of: mtn ls unknown | xargs mv --target-directory=$ROOT/_MTN/conflicts/$(date) *reliable means - no name conflicts and no problems with whitespace in names. Am I right? Best regards, -- Zbigniew Zagórski / software developer / geek / happy daddy / ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] automate get_current_revision [was --non-interactive ... ]
Nuno Lucas pisze: On Feb 20, 2008 10:12 AM, Thomas Keller [EMAIL PROTECTED] wrote: ... Sorry to interrupt, but are you talking about automate get_current_revision_id ? If it is, I make use of it in a script and count on the fact that is returns the same as get_base_revision_id if there are no changes on the workspace. If it's not, forget this... Hey are you sure ? $ /c/Programs/mtn.exe au get_current_revision_id f7325407065d4eef7046931790783e449db1f924 $ /c/Programs/mtn.exe au get_base_revision_id e3a995e66d0c22a5e3c8c872ed09b85d098af81b $ /c/Programs/mtn.exe mtn st Current branch: net.venge.monotone.nuskool Changes against parent e3a995e66d0c22a5e3c8c872ed09b85d098af81b no changes (executable used is official 0.38 exe). IMHO get_current_revision_is is supposed to return an id of revision that would be created by next commit. It can't be same as base_revision id. Unfortunately - as Thomas pointed out - it makes no sense to create revision with no changes, so output of get_current_revision_id doesn't make sense. -- Zbigniew Zagórski / software developer / geek / happy daddy / ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] automate get_current_revision [was --non-interactive ... ]
2008/2/20, Thomas Keller [EMAIL PROTECTED]: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Zbigniew Zagórski schrieb: 31-01-08, Zbigniew Zagórski [EMAIL PROTECTED] napisał(a): Thomas Keller wrote: ... On a related note, if you think of doing commits over automate like I currently do, what is really _lacking_ in automate is a way to let mtn return a valid restricted revision for a given set of paths (i.e. I currently just feed put_revision with the complete output of get_revision). One could of course do the node restriction logic in the client (f.e. for renames), but this is very ugly. How about adding: automate get_current_revision [PATHS...] Which will return current workspace revision restricted with PATHS. Now when automate commands can accept options it will be possible to add --depth and --exclude options also. Hi, I've commited f6cb000f1bbcf35e6458c5e62e10ecef02021752 with implementation of this command. Please review if worried about quality ;) (tests/doc/NEWS). Best regards, Heh... I totally forgot about that thread, and that there is already an implementation for get_current_revision sitting in nvm.automate_current_revision (for quite some time) - but this is not a problem. I'll review your version and we'll take just that. If everything is ok, I'll suspend the old branch. Hmm, sorry for mess i didn't know about that branch. Lot of interesting things are hidden there in nvm Looking at differences: 1. Your version fails if there are no changes in workspace. Dunno if it's good or not. (after few minutes of thinking it's rather good). 2. I think it's reasonable to limit functionality of get_revision to give only revisions form database. (automate_get_revision test needs to be updated) 3. Code is almost the same ... looks like we copy-pasted from same source ;) 4. I'm curious if your code will pass my unittest... I think that if we merge both revs the result will be interesting and usable. I can do it this evening ... -- Zbigniew Zagórski / software developer / geek / happy daddy / ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] restrictions: disabling recursion
Hi all, while fighting with my first lua test (for automate get_current_revision) I've found that restrictions are rather surprising when using --depth=0 command. Reference says that ... For example, n=0 disables recursion ... and i think that it's not absolutely true. Question is what does disabled recursion mean. When I've got following revision(all of them are folders): addedyyy addedyyy/ttt addedyyy/zzz I want to check changes: $ mtn st --depth=0 . Current branch: a Changes against parent 5c11ada5b46d4ac9c809a29d35f92e9bb89e6222 addedyyy I suppose that mtn will restrict me only to current folder. But does current folder includes all files in current folder ? In that case it's very not a problem I'm still not sure. Maybe next case shows my confusion better. I want to see only things added in yyy/ttt subdir: $ mtn st --depth=0 yyy/ttt mtn: warning: restriction excludes addition of 'yyy' but includes addition of 'yyy/ttt' mtn: misuse: invalid restriction (boom, never mind restrictions disabilities now. Lets add yyy/ to restriction also): $ mtn st --depth=0 yyy yyy/ttt Current branch: a Changes against parent 5c11ada5b46d4ac9c809a29d35f92e9bb89e6222 addedyyy addedyyy/ttt addedyyy/zzz Of course we didn't wanted this yyy/zzz here. It's a surprise. Is that also a feature ? So, IMHO it would be feasible to change meaning of --depth in all restrictions to following 0 strictly no recursion, take only explicitly given names 1 + only direct children of explicitly given folders 2 + direct of these folders ... -1 -- infinite recursion Lets assume that implementation is different story. Is that feasible idea? It would follow the least surprise rule path (at least for me). BTW. Does directories support attributes ? Yes they do. This change t would allow operating on directory as an entity. Now it's quite impossible without using tedious --exclude. $ mtn st yyy --depth=0 Current branch: a Changes against parent 5c11ada5b46d4ac9c809a29d35f92e9bb89e6222 addedyyy addedyyy/ttt addedyyy/zzz attr on yyy attr jjj value 1 (boom, i don't want ttt zzz). Best regards, -- Zbigniew Zagórski / software developer / geek / happy daddy / ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] automate get_current_revision [was --non-interactive ... ]
31-01-08, Zbigniew Zagórski [EMAIL PROTECTED] napisał(a):
Thomas Keller wrote:
...
On a related note, if you think of doing commits over automate like
I currently do, what is really _lacking_ in automate is a way to
let mtn
return a valid restricted revision for a given set of paths (i.e. I
currently just feed put_revision with the complete output of
get_revision). One could of course do the node restriction logic in
the client (f.e. for renames), but this is very ugly.
How about adding:
automate get_current_revision [PATHS...]
Which will return current workspace revision restricted with PATHS.
Now when automate commands can accept options it will be possible to
add --depth and --exclude options also.
Hi,
I've commited f6cb000f1bbcf35e6458c5e62e10ecef02021752 with
implementation of this command. Please review if worried about quality
;) (tests/doc/NEWS).
Best regards,
--
Zbigniew Zagórski
/ software developer / geek / happy daddy /
#
# old_revision [d6517813b56675ff4a5e6c67dc391fff3dc1fc36]
#
# add_dir tests/automate_get_current_revision
#
# add_file tests/automate_get_current_revision/__driver__.lua
# content [dc822a42c1e122836b812958cb6aa5e8f2f76cd2]
#
# patch NEWS
# from [757241af97eb81545a0aed186345ae1f3eb43b82]
#to [5ec365e12d5019e6aa57168d9774b9d261319fff]
#
# patch automate.cc
# from [047ae5ab7138ac06ededf854e74597c9b72b0954]
#to [3b00aaab59f25242202fb0768290952122e17583]
#
# patch monotone.texi
# from [e32c720dfae2e30a04cf0e14c306d5c7e25304ce]
#to [93f947bdd8181f8c36ac6a04c926be4d0f45a3c5]
#
--- tests/automate_get_current_revision/__driver__.lua dc822a42c1e122836b812958cb6aa5e8f2f76cd2
+++ tests/automate_get_current_revision/__driver__.lua dc822a42c1e122836b812958cb6aa5e8f2f76cd2
@@ -0,0 +1,59 @@
+
+mtn_setup()
+
+addfile(zoo, blah\n)
+check(mtn(commit, --date=2005-05-21T12:30:51,
+ --branch=testbranch, --message=blah-blah), 0, false, false)
+
+-- ensure that bad restriction paths fails
+check(mtn(automate, get_current_revision, foo-bar), 1, true, false)
+check(fsize(stdout) == 0)
+
+addfile(foox, blah\n)
+addfile(barx, blah2\n)
+
+-- ensure that no resrtiction yields the same as '.' as restriction
+check(mtn(automate, get_current_revision), 0, true, false)
+no_restrict = get(stdout)
+
+check(mtn(automate, get_current_revision, .), 0, true, false)
+with_restrict = get(stdout)
+check( no_restrict == with_restrict)
+
+check(mtn(automate, get_current_revision, foox), 0, true, false)
+foo_restrict = get(stdout)
+check( qgrep(foox, stdout) )
+check( not qgrep(barx, stdout) )
+check( not qgrep(zoo, stdout) )
+
+
+check(mtn(automate, get_current_revision, barx), 0, true, false)
+check( qgrep(barx, stdout) )
+check( not qgrep(foox, stdout) )
+check( not qgrep(zoo, stdout) )
+
+-- check subdirectory restrictions
+mkdir(ttt)
+mkdir(ttt/yyy)
+mkdir(ttt/xxx)
+
+addfile(ttt/yyy/zzz, blah\n)
+addfile(ttt/xxx/vvv, blah\n)
+
+check(mtn(automate, get_current_revision, ttt/), 0, true, false)
+check( qgrep(ttt, stdout) )
+check( qgrep(zzz, stdout) )
+check( qgrep(vvv, stdout) )
+check( not qgrep(foox, stdout) )
+check( not qgrep(barx, stdout) )
+
+check(mtn(automate, get_current_revision, --depth=0, ttt, ttt/xxx, ttt/xxx/vvv), 0, true, false)
+check( qgrep(ttt/xxx/vvv, stdout) )
+-- XXX: check node_restriction for
+-- looks like yyy gets into revision even if we explicitly
+-- forbidden recursion
+-- check( not qgrep(yyy, stdout) )
+check( not qgrep(zzz, stdout) )
+check( not qgrep(foox, stdout) )
+check( not qgrep(barx, stdout) )
+
--- NEWS 757241af97eb81545a0aed186345ae1f3eb43b82
+++ NEWS 5ec365e12d5019e6aa57168d9774b9d261319fff
@@ -53,6 +53,9 @@
directories. The typical case of listing files that need attention
now runs at least four times faster.
+- 'automate get_current_revision' retrieves restricted revision
+ represented by current workspace
+
Wed Dec 12 21:21:15 UTC 2007
0.38 release.
--- automate.cc 047ae5ab7138ac06ededf854e74597c9b72b0954
+++ automate.cc 3b00aaab59f25242202fb0768290952122e17583
@@ -1194,6 +1194,47 @@ CMD_AUTOMATE(get_revision, N_([REVID])
output.write(dat.inner()().data(), dat.inner()().size());
}
+// Name: get_current_revision
+// Arguments:
+// 1: list of restriction paths
+// Added in: 7.0
+
+CMD_AUTOMATE(get_current_revision, N_([PATHS ...]),
+ N_(Shows change information for a workspace),
+ ,
+ options::opts::exclude | options::opts::depth)
+{
+ temp_node_id_source nis;
+ revision_data dat;
+ revision_id ident;
+
+ roster_t new_roster;
+ parent_map old_rosters;
+ revision_t rev;
+ cset excluded;
+
+ app.require_workspace();
+ app.work.get_parent_rosters(old_rosters
Re: [Monotone-devel] botan 1.7.3
Markus Schiltknecht wrote:
... in general about updating botan to 1.7.3 in monotone
...
61b03ea355c0cfed3fc62b3c7014b106a1e61119 [EMAIL PROTECTED]
2008-02-17T21:22:45 net.venge.monotone.botan
[This is actually patch for botan itself. So I'm cross posting to
botan-devel]
There is another problem with the new code. This patch visualizes issue:
--- botan/bit_ops.cpp ebab53284a6ab9a749188fcbe417c8dcc73ac052
+++ botan/bit_ops.cpp 3bb7a0fd68305ca2ff7a071798aa4419f783cf02
@@ -64,10 +64,10 @@ u64bit reverse_bytes(u64bit input)
*/
u64bit reverse_bytes(u64bit input)
{
- input = ((input 0xFF00FF00FF00FF00) 8) |
- ((input 0x00FF00FF00FF00FF) 8);
- input = ((input 0x) 16) |
- ((input 0x) 16);
+ input = ((input 0xFF00FF00FF00FF00ull) 8) |
+ ((input 0x00FF00FF00FF00FFull) 8);
+ input = ((input 0xull) 16) |
+ ((input 0xull) 16);
return rotate_left(input, 32);
}
g++ 3.4.5 complaints about old code that those big integer constants:
a.cpp:9: error: integer constant is too large for 'long' type
BTW g++ (GCC) 4.0.4 20060507 (prerelease) (Debian 4.0.3-3)) also fails
to compile original code.
--
Zbigniew Zagórski
/ software developer / geek / happy daddy /
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] ..more notes about .nuskool
2008/2/4, Markus Schiltknecht [EMAIL PROTECTED]: However, ATM nvm.nuskool is pretty simplistic and works over HTTP exclusively, ignoring any branch patterns and synchronizing all revisions in the database. Just for curiosity how big databases you've managed to sync ? Is it useful for syncing n.v.monotone* branch set ? I'd like to go for something more RESTful, as far as the HTTP interface is concerned. This should make better use of the HTTP caching infrastructure and would probably even allow something like the mtn dumb server interface. If we still need olskool netsync (do we?), we should encapsulate the communication channel stuff from the nuskool new DAG based refinement thingie, very much like the current refiner is separate. ... 1.) sync from mtn client to dumb http server with static files 2.) sync from mtn client to clever http server via scgi to mtn server 3.) sync from mtn client to clever mtn server via netsync While the first two require a state-less approach, fitting HTTP, the third option doesn't. I'm not sure if it's worth exploiting that. Probably not. And the first option is quite different in that we cannot put any logic into the server, for obvious reasons. Maybe a little not related opinion. I've been thinking a lot about all of this while hacking on n.v.m.dumb. I know that current dumb tool can be much more faster if it would be possible to retrieve complete merkle_dir (or anything representing state of the database/project) in some fast way. The HTTP time wasn't too important, the most time consuming was retrieving/toposorting all revisions (not so bad) and all the certs for all revisions (ages). It's slow also for current netsync protocol so I think there must be some idea shift about synchronization. How to synchronize databases without retrieving WHOLE of tree and ALL certs. -- Zbigniew -zbigg- Zagórski / software developer / geek / happy daddy / ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] --non-interactive: run in non-interactive
2008/1/31, William Uther [EMAIL PROTECTED]: Why not just make sure the user has a lua hook with a passphrase in it. Perhaps something like this (untested): cat newhook.lua EOF function get_passphrase_bogus(keypair_id) return this is probably not the passphrase end if (get_passphrase == nil) then get_passphrase = get_passphrase_bogus end EOF Because mtn treats password from lua hook as weak. If it's nil, empty or wrong then monotone asks for correct password on tty. We could fix this, it's one thing, but it's only specific behaviour of one hook. My reasoning is it would be good to have contract between user and monotone which clearly says don't touch stdin/tty and don't ask questions because for example you are part of some automation interface.. On the other hand i don't know how current code can enforce this contract esp in lua hooks. I'll look at that ... ... The other option would be to encourage people to use ssh-agent. Perhaps automating that process for them would help: Export their keys in the right form, check if the SSH_AUTH_SOCK environment variable is set, and if it is then see if the key is loaded and if not, load it in for the user (prompting for the password yourself). I don't know how it works currently for default but when i'm on unix box and have ssh-agent env setup (aka connected via ssh) mtn always automatically adds my key to agent so I enter password only once in such agent life. However on windows i don't see this behaviour. I always have pageant running and key can be added only by explicit command. -- Zbigniew -zbigg- Zagórski / software developer / geek / happy daddy / ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] --non-interactive: run in non-interactive
2008/1/31, Zack Weinberg [EMAIL PROTECTED]: 2008/1/30 Zbigniew Zagórski [EMAIL PROTECTED]: ... In current state this option will affect password prompt only, but it can be used in future commands to check if user wants to make decisions. I approve of the concept in general; however ... Good. After five minutes it appeared that almost all functions from keys.hh must accept app_state instead of lua_hooks only: I have to veto anything that does anything like that, because we're in the process of removing the app_state structure altogether. I'm in I was not aware of this fact :/ That's a pity. the middle of rototilling keys.cc and key_store.cc right now and I can't guarantee what they will look like when I'm done, but - I expect that the right thing for you to do is save the option in the key_store object when that object is constructed, if that makes sense? I'll look at this and in general i'll look at those changes. I understand that you're speaking about experiment.encapsulation branch. Also, I wonder if a --passphrase-fd=NUMBER option would make sense for your work. This idea comes from GPG - if the option is given, monotone would read any passphrase it needs from that file descriptor rather than the terminal. You'd make the file descriptor a pipe, and if monotone tries to read from it, pop up a password-prompt dialog box. (I don't actually know how to code that on your end but I'm sure it's possible.) Well it's a great idea, i though about that. However ... I'm almost sure that we don't want to touch file handles inheritance/passing between process on win32. Simply I don't know how to do that (I know only about inheritance). (+1 for simple and clear POSIX/unix architecture) Second. For example java library gives you possibility to control only stdin/stdout/stderr inputs of subprocess. And we want/need some java interfaces to monotone. -- Zbigniew -zbigg- Zagórski / software developer / geek / happy daddy / ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] --non-interactive: run in non-interactive
Hello,
I'm hacking silently at mtteam again I hit the wall of safe commit.
Safe means that I'm sure that monotone will not ask anything from
stdin/tty user but fail miserably with some error message. Thus it's
guarantee that it will never hang up.
The only two places that monotone interacts with user are:
- commit
- cert, approve, testresult
- merge*
- genkey (doesn't count, because it has automate counterpart)
From my point of view interesting commands are commit and cert*
derivatives. They can ask for password. GUI doesn't like it.
So i invented --never-prompt-password, and started to hack ;). Later
on I've decided that --non-interactive global option will be better.
When you'll specify this option to mtn it will never ask for a
password. If the password is needed (no lua hook, no key in ssh-agent)
it will clearly fail with some informative message.
In current state this option will affect password prompt only, but it
can be used in future commands to check if user wants to make decisions.
back to the patch ...
After five minutes it appeared that almost all functions from keys.hh
must accept app_state instead of lua_hooks only:
-get_private_key(lua_hooks lua, ...
+get_private_key(app_state app, ...
...
-get_passphrase(lua_hooks lua, ...
+get_passphrase(app_state app, ...
...
-void encrypt_rsa(lua_hooks lua,
+void encrypt_rsa(app_state app,
...
-void decrypt_rsa(lua_hooks lua,
+void decrypt_rsa(app_state app,
...
and so on. Is it ok for you ?
Core of patch consist of
1. adding --non-interactive run in non-interactive mode (never ask
questions)
2. modification of get_passphrase(keys.cc):
@@ -75,7 +75,7 @@ void
// 'force_from_user' means that we don't use the passphrase cache,
// don't use the get_passphrase hook.
void
-get_passphrase(lua_hooks lua,
+get_passphrase(app_state app,
rsa_keypair_id const keyid,
utf8 phrase,
bool confirm_phrase,
...
string lua_phrase;
- if (!force_from_user lua.hook_get_passphrase(keyid, lua_phrase))
+ if (!force_from_user app.lua.hook_get_passphrase(keyid,
+ lua_phrase))
{
phrase = utf8(lua_phrase);
N(phrase != utf8(),
F(got empty passphrase from get_passphrase() hook));
}
+ else if( app.opts.non_interactive )
+{
+ F(reading passphrase from terminal forbidden by explicit
+option);
+}
else
{
char pass1[constants::maxpasswd];
Do you like this idea ? I'll send finished patch for review.
PS. I know that commit from automate would be the best way but we
can't wait for it (sadly, it's too big task for me to do it now ).
mtteam is in almost usable state and the only blocking issue is
commit. We'll gladly switch to 'automate commit' when it will be done.
PS2. I'm sure guitone also looks for solution to commit from GUI
problem.
Best regards,
--
Zbigniew Zagórski
/ software developer / geek / happy daddy /
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] unhexification of revision hashes
2008/1/28, Markus Schiltknecht [EMAIL PROTECTED]: Hi all, ... I've just committed a revision 47dc584d4ca8799f686b20ce9bf5c59eb69f6d3c into branch n.v.m.experiment.db-compaction. Todays fixes made it pass all unit and lua tests, and together with the addition to NEWS, I now consider that revisions to be ready for landing on mainline. Please review. Hi, I don't remember reasons for this change besides db compaction. However I see a small a performance hit on windows: whathex 0.38 log --brief | 46 | 39 graph| 2| 0.8 ls branches | 7.7 | 6 (seconds, all dev null, monotone db, nvm head) Should it be slower? Faster ? Are those test cases feasible ? BTW. What are the cxxflags of official windows build, my build is -O2 -g -Wall stripped, maybe this perf hit is caused by bad flags. PS. I see ~10 size loss on two databases (156-137 monotone, 9-7.6 private db) so this db compaction is real. Regarding review I'm not familiar with codebase but i'll try. Regards, -- Zbigniew -zbigg- Zagórski / software developer / geek / happy daddy / ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] unhexification of revision hashes
Markus Schiltknecht pisze: Hello Zbigniew, Zbigniew Zagórski wrote: I don't remember reasons for this change besides db compaction. Hey, thanks, that's great and pretty instant help. ;-) Ha... I think it's Graydon leave effect ... everybody is now on steroids ;) See releases ? ViewMtn, Guitone, mtteam is also preparing a demo ... Hope this enthusiasm will last for long... ... Last I checked, I saw very small performance improvements, so these numbers are looking suspicious to me. Can you recheck the CXX flags, please? Unfortunately I've recompiled head, ran tests and times are the same as with 0.38, so your code is slower. I didn't wanted to bring bad news ... :( BTW. All tests on hot DB and repeated few times. BTW: please don't drop the mailing list and reply to all. Or can the list admin make the mailing list set a reply-to header, or something? Hmm, it's my common mistake to hit Reply only but this time I'm innocent. +1 for Reply To header set by mailing daemon. -- Zbigniew -zbigg- Zagórski / software developer / geek / happy daddy / ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Future of monotone
2008/1/27, Koen Kooi [EMAIL PROTECTED]: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thomas Keller schreef: | So where lacks monotone the most? Speed. Try doing simple things like 'mtn log', 'mtn annotate' or even 'm tn sync' with an OE database and you start to see how badly mtn scales. We keep mtn around because half the coreteam hates git with a passion... Well i didn't hit this wall but i believe it's true. BTW. Anyone tried to analyze differences in design choices/implementation between monotone and other distributed/DAG based ... never mind the name similar VCS-es like git, bazaar, mercurial, darcs ? Is this all about security? Maybe it's storage problem... Maybe DAG based approach ... Maybe the branching implemented using certs (you can't know where rev belongs without reading certs) it hits netsync mainly (and never finished dumb protocol) Why monotone is so slow or why monotone appears as slow. Just some rhetorical questions ... Best regards, -- Zbigniew -zbigg- Zagórski / software developer / geek / happy daddy / ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Fwd: [Monotone-devel] Perhaps strange request: partial per-file commit
[ William, for double post Why this list doesn't set Reply-to header ? ] 2008/1/16, William Uther [EMAIL PROTECTED]: I like this 'commitdiff' concept. It is a simple command that could be +1 for commitdiff from here. It's very good idea. The only real question is how this affect items that monotone tracks that are not represented in a normal diff format - file and property adds, deletes and renames, etc. I think the the best would be to monotone bagan understand diff that it produces. mtn diff already says everything (although in non-official way). In that case it would possible to: mtn diff patch1.diff vi patch1.diff mtn commitdiff patch1.diff BTW. Am I missing something, but isn't mtn diff output almost ready revision data ? # # old_revision [764b735eb435c1e345be2f8a7425dd0bad7f896b] # # add_file aclocal.m4 # content [a3f381015bad6068041d928d92e1fe9aea3a402f] # # patch tinfra/test_main.cpp # from [fe3712f886278197fd324eddf8131b601c1dc55b] #to [0a730d059e26f163b055fee763e8d8c4b682b94b] # # set Bakefiles.bkgen # attr mtn:execute # value true # --- aclocal.m4 a3f381015bad6068041d928d92e1fe9aea3a402f +++ aclocal.m4 a3f381015bad6068041d928d92e1fe9aea3a402f @@ -0,0 +1,1898 @@ +# generated automatically by aclocal 1.9.5 -*- Autoconf -*- + ... -- Zbigniew -zbigg- Zagórski / software developer / geek / happy daddy / -- Zbigniew -zbigg- Zagórski / software developer / geek / happy daddy / ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] empty certificates
Hello all, I see there is little inconsistency in treating cert values. Some places support empty cert values (THEM) some not (empty cert value == 0 bytes length string). Commands supporting THEM: - netsync push/pull - automate certs - automate get_packets_for_certs - mtn cert h: foobar Namely it's possible to create cert with empty value (and it's possible since long time) and sync it but ... Commands don't support THEM - ls certs - packet read (mtn read) So. I think we should support THEM because someone might have THEM already in databases (i did it for example). If no one has objections I will add support for THEM in two places mentioned above. PS. Are there any other known places that deal with cert values that might be empty ? Regards, -- Zbigniew -zbigg- Zagórski / software developer / geek / happy daddy / ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Is this the right mailing list? [Was: upgrading 0.36-0.37: mtn: fatal: std::logic_error: roster.cc:186: invariant 'fetching nonexistent entry from children' violated]
2007/12/6, Arthur A. Gleckler [EMAIL PROTECTED]: Have I sent my earlier messages to the right mailing list? Yes this is correct mailing list, your problem is noted. However nobody currently has time/idea how to solve your problem. Sorry. Someone surely is investigating your problem silently ... Only one thing I can propose to you is to go back to 0.36. There was no database schema changes so this step back should be simple. You can also check if previous revisions can be checked out/updated to; it would surely tell if it's only one rev broken or there is something more. -- Zbigniew -zbigg- Zagórski / software developer / geek / happy daddy / ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Is this the right mailing list? [Was: upgrading 0.36-0.37: mtn: fatal: std::logic_error: roster.cc:186: invariant 'fetching nonexistent entry from children' violated]
2007/12/6, Arthur A. Gleckler [EMAIL PROTECTED]: Alas, I tried that, but I still get the same error. I'm afraid that something has now corrupted my database for that branch. [cut] Here is the result: mtn: misuse: rename target 'lisp/personal-site-lisp/jde/java/src/jde/debugger/Jdebug.java' already exists In .../jde/java/src/jde/debugger you've got two files: JDEbug.java - 0x13e8840 Jdebug.java - 0x13e88c0 and looks like your filesystem is case insensitive (JDEbug.java is same as Jdebug.java). Also in .../vim-7.18 you've got similar duplicates: COPYING - 0x13777f0 copying - 0x1378f80 try to fix it on some other machine or more specifically on site with in case sensitive FS. Nevertheless it's kind of bug that monotone crashes in so awful way giving meaningless message. I know that bug has active victims on win32 some time ago, now mac users joined the club. -- Zbigniew -zbigg- Zagórski / software developer / geek / happy daddy / ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Fw: [bug #21706] automate packet IO broken on 0.37
2007/12/3, Nathaniel Smith [EMAIL PROTECTED]:
So people don't miss this...
$ mtn automate packet_for_rdata 73523223ab76d83954f6284243c69a5b3726b91d
| mtn read
mtn: warning: unknown packet type: 'rdata'
mtn: misuse: no packets found on stdin
Well, after a small investigation I see that packet.cc was rewritten
some time ago (probably together with regex changes) and following
strange lines were added:
if (type == rdata)
data_packet(args, body, true);
if (type == fdata) // should be else if
data_packet(args, body, false);
else if (type == fdelta)
else
{
W(F(unknown packet type: '%s') % type);
return;
}
so looks like rdata packet is actually read, message is warning only.
After some checks i see that revision finally lands in destination db.
I don't have machinery for building monotone but following patch
should fix this warning.
--- packet.cc 35ad4a2b884b276ff41d03d4efd9fb6e9b62d048
+++ packet.cc 58beaca7a4c3e03fa496a34a11107f2fb12cb4b9
@@ -242,7 +242,7 @@ feed_packet_consumer
{
if (type == rdata)
data_packet(args, body, true);
-if (type == fdata)
+else if (type == fdata)
data_packet(args, body, false);
else if (type == fdelta)
fdelta_packet(args, body);
Sorry for false alarm.
-
But still there is something wrong (or only changed) in packet IO
because mtn read used by mtndumb (net.venge.monotone.dumb) fails
miserably with following error:
mtn: error: malformed packet: too many arguments in header
I'm investigating issue (i don't know what packet sequence is causing
this error) if this was mtndumb or mtn issue (i don't have to say that
on 0.36
everything worked perfectly).
Regards,
--
Zbigniew -zbigg- Zagórski
-- software developer -- geek -- happy daddy --
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Fw: [bug #21706] automate packet IO broken on 0.37
2007/12/3, Zbigniew Zagórski [EMAIL PROTECTED]: mtn: error: malformed packet: too many arguments in header Failing packet is: [rcert 57fb649ce6809a7f806dd481554f7edbcc95f141 changelog [EMAIL PROTECTED] KiBpbml0aWFsIGNvbW1pdDogYnJhbmNoIGFuZCBsYWJlbHMgbGlzdGVyCiogc2ltcGxlIHRl c3QgYWRkZWQK] RSc+EaqFfb/FQjDSw3KPOxqWEjc3Bi87ylTAbwVxjFKF570Cwyu/FU6JrVavw/w9Wm+Ys17q AThy6Z/RyLc+HFolzGg+OtppE7U3WFBnrMmn+zwSiJGMfovKM+4JbA/LsHIpSOJkbhdIpfZf zzBmUC+Bgb63kPIiXS+RWgCCN/c= [end] anyone knows if this kind of packet is correct (0.36 reads it)? I've got it. I've unbroken last parameter (the base6t(cert_value)) to fit one line and mtn accepts it :). Correct packet: [rcert 57fb649ce6809a7f806dd481554f7edbcc95f141 changelog [EMAIL PROTECTED] KiBpbml0aWFsIGNvbW1pdDogYnJhbmNoIGFuZCBsYWJlbHMgbGlzdGVyCiogc2ltcGxlIHRlc3QgYWRkZWQK] RSc+EaqFfb/FQjDSw3KPOxqWEjc3Bi87ylTAbwVxjFKF570Cwyu/FU6JrVavw/w9Wm+Ys17q AThy6Z/RyLc+HFolzGg+OtppE7U3WFBnrMmn+zwSiJGMfovKM+4JbA/LsHIpSOJkbhdIpfZf zzBmUC+Bgb63kPIiXS+RWgCCN/c= [end] You can test it on any long changelog cert. For example another failing packet is changelog of t:monotone-0.37. Regards, -- Zbigniew -zbigg- Zagórski -- software developer -- geek -- happy daddy -- ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Fw: [bug #21706] automate packet IO broken on 0.37
2007/12/3, Zack Weinberg [EMAIL PROTECTED]: If 0.36 read this packet, then subsequent versions should too. This looks like an easy fix. I've also found it (feed_packet_consumer::rcert_packet at packet.cc). Args reader should be avare that value part of cert can be splitted into multiple lines. This is quick and dirty patch in attachment that should work (sorry i don't have env to build test it). The packet reading code doesn't really have comprehensive tests; would you be interested in writing some? Well. In ideal world yes in reality - not enough time. (reason == subject(last(signature.split())). For example I've never found enough time to correctly build monotone+unitests on my machine (partly because my laptop is very slow and mingw slows it even more in comparision to linux.). Never mind understanding the whole Lua test machinery (C++ unitests looks familiar). In the meantime I'm using packet_io in via mtndumb and I will detect problems in the easiest and cheapest way: end-user way ;). Greetings, -- Zbigniew -zbigg- Zagórski / software developer / geek / happy daddy / mtn_read_cert_packet.patch Description: Binary data ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] 0.37 Win32 binary?
2007/11/6, Stephen Leake [EMAIL PROTECTED]: There is still no 0.37 Win32 binary on http://monotone.ca/. Should I build one? I assume I just do make distrib? I don't know anything about make distrib but IMHO best way is to just use InnoSetup GUI and open win32/monotone.iss and click compile. This should be enough. Hint1. In official source code there is no win32/monotone.bmp Hint2. In monotone.iss at end of file list there are hardcoded links to someone mingw installation dir, you may change them to yours. -- Zbigniew -zbigg- Zagórski -- software developer -- geek -- happy daddy -- ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] 0.36 win32 download broken
Hello all, permissions are messed up in /downloads/0.36 on monotone.ca site: Forbidden You don't have permission to access /downloads/0.36/monotone-0.36-setup.exe on this server. http://monotone.ca/downloads/0.36/monotone-0.36-setup.exe -- Zbigniew -zbigg- Zagórski -- software developer -- geek -- happy daddy -- ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] merge commands arguments
Hello all, I see some inconsistency in merge command parameters. 1. explicit_merge merge They lack possibility to override message by '--message' and '--message-file' arguments 2. merge_into_dir Has all interesting arguments to customize revision info but: Why one can't merge from explicit revision but only from head of some branch ? Maybe merge_into_dir should have syntax changed from: merge_into_dir SOURCE-BRANCH DEST-BRANCH DIR to merge_into_dir SOURCE-REV DEST-BRANCH DIR so one can use any selector as SOURCE-REV to choose revision. It may be convenient to have those parameters. Don't know whether it's 'by design' or just anyone needed to make it consistent. I'm thinking about fixing those issues so I'm just asking for comments. -- Zbigniew -zbigg- Zagórski -- software developer -- geek -- happy daddy -- ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Question on layering
2007/2/22, Nathaniel Smith [EMAIL PROTECTED]: Network traffic is harder to fix. I can't tell either way whether that's going to be a problem long term... we might be able to optimize for space more (there's at least some win possible just by using stream compression instead of the current packet-by-packet compression), and average bandwidth keeps getting wider... Certainly I think that making packets decompressed as default would be good idea. While testing the n.v.m.dumb on bigger databases I see that most of monotone effort is at creating/reading packets. Maybe it's compression which takes some time. No i didn't profiled it, but it may be reasonable for transport (netsync/dumb) to decide if compression is needed. Maybe support two kinds of packets withwithout compression ? Compressed by default, but uncompressed with specific option .. That's would make mess in code, but maybe it would useful. Again, returning to n.v.m.dumb, are there any chances to make cert id a public entity, so we can query for them by automate ? (BTW. I'm polishing n.v.m.dumb so in few commits it will be usable for small projects). -- Zbigniew -zbigg- Zagórski -- software developer -- geek -- happy daddy -- ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] annotate brief with tags
Hello all. I've got one small improvement suggestion for automate brief output. How about showing tags instead of revisions in line brief if revision has tag ? Output would look like this: - : WX_ARG_ENABLE(no_exceptions, : WX_ARG_ENABLE(permissive, ... : WX_ARG_ENABLE(no_deps, ... WX_2_8_0_rc3 wx-team 2006-12-12: WX_ARG_ENABLE(vararg_macros, WX_2_7_1 wx-team 2006-12-12: WX_ARG_ENABLE_PARAM(universa WX_2_5_5 wx-team 2006-12-12: WX_2_7_0 wx-team 2006-12-12: WX_ARG_ENABLE(compat24, ... : WX_ARG_ENABLE(compat26, ... WX_2_5_5 wx-team 2006-12-12: : WX_ARG_ENABLE(rpath, ... : : dnl - I know it's not always usable, but is usable for scenarios like i do I've got mirror databases of some known packages like wxWidgets, python. I do import for each release so in fact each revision is tagged, and thus this improvement is usable for tracking changes in releases. OTOH for example in monotone database where tag revisions are usually only those with NEWS update it's rather not usable. I've implemented it partially, so if there is interest in such improvement please give feedback, so i'll polishsubmit patch. -- ::: zbigg : Zbigniew Zagórski :: :: z.zagorski on gmail ::: GG:5280474 :: ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] annotate brief with tags
Thomas Moschny wrote: On Tuesday 09 January 2007 20:33, Zbigniew Zagórski wrote: I've got one small improvement suggestion for automate brief output. How about showing tags instead of revisions in line brief if revision has tag ? [...] I've implemented it partially, so if there is interest in such improvement please give feedback, so i'll polishsubmit patch. What does your code do in case multiple tags are attached to a revision? Heh, nothing particular. It just picks random cert where name == 'tag'. If that's a problem, then same applies to author/date certs. One can have multiple author/date certs. I see no reasonable solution here ... -- ::: zbigg : Zbigniew Zagórski :: :: z.zagorski on gmail ::: GG:5280474 :: ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] mtnplain (aka dumb) revision order, epoch
Hi, Nathaniel Smith [EMAIL PROTECTED] wrote: On Fri, Jun 23, 2006 at 09:40:31AM +0200, Zbigniew Zagórski wrote: ... Question: How to obtain parent REV(s) from rdata packet without using 'mtn read' ? I thought that someone else already fixed this in the current head of the .dumb branch -- the better solution is to make sure that when we write things out to the DATA file, we write them in the correct order, so that later on they can just be read in directly like they are now. It's possible that this is in fact fixed, but you're trying to pull from a dumb repository that was created before this was fixed, so the packets are still in the wrong order. I suggest doing a push into a fresh dumb repository, and then pulling from that, and seeing if that fixes the problem. Unfortunately, ... you're right. I followed probably outdated Riccardo's e-mail in which he written reordering is not ready :/. It works. Now I see that my effort was so stupid :/. Ach ... And yes I must have got some old 'dumb' repository which i overlooked. Sorry for bugging with this. Second problem. What needs to be done to support them in mtn-dumb is: 1) create a new packet type for epochs 2) for each branch in the db, add this packet to the merkle trie being synced. Make sure to put these packets as early as possible; just like revisions should come before certs, epochs should come before revisions, and even before files. ... mtn read for locks on the database.) (This is exactly how an in-monotone implementation of epoch packets would do, except with fewer caveats.) Now after reading a little i think that 2) is perfect solution. I'll do it so. When it'll be finished, then 'mtnplain' will be quite complete solution. PS. I think that 'plain' is better name for 'dumb'. And my proposition is to name the tool is 'mtnplain'. Hmm, I'm not sure. There are two problems: 1) dumb is sort of a stupid name, but it has a lot of history behind it :-). The standard word for using HTTP/FTP/etc. as a VCS transport has been dumb for many years now, and it's been used by a lot of different people (starting with the Arch people). 2) plain is very ambiguous. For instance, surely plain monotone is what you get when you go to http://venge.net/monotone/downloads/ right? Hmmm, for now lets leave it to others. In fact i don't care about name. ... Want to send me a key, so you can use the venge.net server to distribute your work? You've already added it some time ago, but from then i went sleep (in a mean of development) and didn't pushed anything. I'll push these changes ASAISFTFOS (as soon as.i find some free time for open source). -- Best regards, Zbyszek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] user-defined external mergers...
Vladimir Vukicevic wrote:
On 6/16/05, Richard Levitte - VMS Whacker [EMAIL PROTECTED] wrote:
The current idea is that the user can specify commands in the
environment variables MONOTONE_MERGE2 and MONOTONE_MERGE3. They can
contain the following printf-like items:
Hmm, why do things via an environment variable when it's already
possible to set up arbitrary hooks using ~/.monotone/monotonerc or
MT/monotonerc? I think exposing these bits as environment variables
by default really makes it such that you have to expose a lot of other
config via environment variables as well..
I don't agree, i think that it would be very convenient. Just look how
different is to write:
export MONOTONE_MERGE2=something
vs.
function merge3(ancestor, left, right)
local afile = nil
local lfile = nil
local rfile = nil
local outfile = nil
local data = nil
lfile = write_to_temporary_file(left)
... and about 20-30 lines more (yep i know copy and paste), and you must know
Lua at least a little, and if for some magic reason specification of callbacks
would change
then all carefully crafted callback code will become unusable.
Otoh, i don't know Lua and Lua in monotone internals, but maybe following would
good idea.
If Lua supports kind of global variables, then variables such as those
proposed by Richard and many more could be set in rc file as global variables,
so
config would look like this:
merge2_command = something %x %y %z
...
and default merge2 callback will use 'merge2_command' variable.
Also, another idea very different to callbacks, but maybe useful for things like
'ignore_file (filename)' callback. How Lua/Monotone. Instead of updating
ignore_file
callback we can modify it to use some internal table of rules, and modify those
rules like this:
add_ignored_files( /core$ )
add_ignored_files( { %.a$, %.o$ } )
or even:
some_global_list_of_ignore_patterns.append( /core$ )
some_global_list_of_ignore_patterns.append( { %.a$, %.o$ } )
Default 'ignore_file' callback would look like this (pseudo code) :
function ignore_file(name)
for each pattern in some_global_list_of_ignore_patterns
if string.find(name, pattern) return true
end
return false
end
And ignore_file(name) would look like that:
Finally going far further future configurations would look like those
Workspace:
passphrases.append( [EMAIL PROTECTED], agent would be better idea )
merge2_command = mybestmerge2tool %z %y
merge3_command = mybestmerge3tool %z %y %z
Server:
accepted_netsync_write.append( mycollection, [EMAIL PROTECTED] )
passphrases.append( [EMAIL PROTECTED], apart from anything it rulez! )
Whole issue is how LUA embedded in monotone plays with global variables.
My 2 cents as satisfied, happy monotone user.
DISCLAIMER: i don't know LUA (for now).
--
::: zbigg : Zbigniew Zagórski ::
:: zzbigg (at) o2 (dot) pl ::: GG:5280474 ::
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
