[Monotone-devel] Re: 0.48 rants
Hi. 2¢ from humble user. From: Lapo Luchini l...@lapo.it I like it quite a bit using EDITOR=nano +14... I was thinking, should be the default hook that adds +14 to the editor name? (maybe recognizing it in a short list of ones that *do* support that +N thing I wasn't aware of) From: Ethan Blanton e...@psg.com I agree with the various comments running around that +14 (or whatever) is easy enough. Long story short, on Windows, I ended changing the `edit_comment` hook to include '+14', like that: if (not string.find(exe, [^%w_.+-:\\])) then -- safe to call spawn directly - if (execute(exe, tname) ~= 0) then + if (execute(exe, '+14', tname) ~= 0) then I'd love to have a hook working the way Lapo specified, although it could be tricky to guess the editor name. On my system it is: C:\set|grep EDITOR\|VISUAL EDITOR=C:\vim\vim72\vim.exe VISUAL=C:\vim\vim72\gvim.exe But the best solution to date is: a) An RFC-822ish header block followed by one blank line, followed by the commit message, followed by a magic separator and the boilerplate text which I can then safely ignore. ;-) b) The commit message leading things off, followed by a magic separator and the metadata, followed by boilerplate I can safely ignore. I like the idea. I tried to see how it would look like, and… how about that? Not exactly in line with the ideas above, but fairly linear and clear — at least for me. :) #v+ MTN: Enter commit message on the first line above. MTN: Lines beginning with 'MTN:' are removed. MTN: Leave message empty to abort commit. MTN: MTN: Commit Metadata MTN: Author, Date and Branch may be modified as required. Revision: d8f494e0ad3e0ee03bcb98e103acdd9f03c769ff Parent: 06b854ae2105db88b2bfe7fda20933e448f6f2b6 Author: m...@twine.pl Date: 2010-07-19T18:48:58 Branch: master MTN: MTN: Changes list, will be included in log. Changes against parent 06b854ae2105db88b2bfe7fda20933e448f6f2b6 patched x #v- Sincerely, -- Marcin W. Dąbrowski ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Possible bug in `mtn log`?
Hi. Today I hit something weird, when trying to see the history of one of the files in my repository - `mtn log filename.ext` is showing logs for other files than 'filename.ext'. I tried to find minimal case, and running the sequence you can see presented below hits the bug - or to say this in other words — it shows not exactly the information I'd like to see. #v+ mtn -d mtn.mtn db init mtn -d mtn.mtn setup . -b mtn.bug.log echo x example.txt mtn add example.txt mtn ci -m Added new file. mkdir sec cd sec mtn -d ../mtn.mtn setup . -b mtn.bug.sec echo y second.txt mtn add second.txt mtn ci -m Added new file, second branch. -b mtn.bug.sec cd .. mtn up -r h: -b mtn.bug.log rm -rf sec mtn merge_into_dir --update -m merge_into_dir src mtn.bug.sec mtn.bug.log sec cd sec mtn log --no-merges second.txt #v- I see two changelogs printed. I don't know why I see the changelog for example.txt, nor why the order is chronological (normally it should be reverse chronology - usually it is). So - is this by design (no, really?), or a bug? PS: mtn version --full gives monotone 0.48 (base revision: 844268c137aaa783aa800a9c16ae61edda80ecea) Running on : Windows NT/2000/XP/2003 (5.1, build 2600, Service Pack 3) on ia32 (level 6, rev 3846) Sincerely, -- Marcin W. Dabrowski ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] setup creates _MTN/mtn.db
Hi. Just my 2¢ as a user. :) On 09 May 2010 02:48:42 +0200, Thomas Keller wrote: Maybe we could make it easier to extract, or better move an internalized database to an external place and vice versa, so people don't have to mess with _MTN/options by hand? One thing I don't like in mtn, is that the database path is absolute. Monotone can read relative path (relative to $CWD) when I put it in options by hand, but replaces that with absolute one (doesn't matter if it's found or not). a way to find a database only by its name (ie. -d foo would look for and find $HOME/.monotone/databases/foo.mtn) Lovely idea. Having a list of places where monotone can search for databases would help a lot. Now, my workspace isn't self-contained, because the absolute database path in options forces me to either leave the workspace where it is, or edit options file when I do a little housekeeping with my directories. (Ahead of the question: yes, moving workspaces is sometimes needed, and I need all the files there — not only these handled by monotone, so cloning or copying just the db is not the answer.) There could be a hook get_default_database_location which could be altered by the user to a different path than the default one underknees $HOME, stuff like that. That would help much. :) Sincerely, -- Marcin W. Dabrowski ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] ViewMTN maintainer
Hi. Btw, if someone here has graphic artist skills... a good idea for a logo is more than welcome ;) Was just exploring ideas. This came out. ;) Rgds., -- mwd / Marcin W. Dąbrowski viewmtn-logo.svgz Description: Binary data ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Possible bug in 'mtn cat'
Hi. Today I've found something weird. As image says more, and working example is even better, with not further ado: - BEGIN BATCH - mtn version --full mtn -d mtn.mtn db init mtn -d mtn.mtn setup . -b mtn.bug.cat echo x example.txt mtn add example.txt mtn ci -m Added new file. mtn cat -r h: example.txt example-check.txt xxd -g8 example.txt xxd -g8 example-check.txt - END BATCH - On my machine, it gives: 2009-09-21 23:49:57,85 C:\tmp\mtn\mtn-cat-bug $ mtn version --full monotone 0.45 (base revision: a19f8b2017c81c3c6c8b2bb3247f865f6ed4e5a9) Running on : Windows NT/2000/XP/2003 (5.1, build 2600, Service Pack 3) on ia32 (level 6, rev 3846) C++ compiler: GNU C++ version 3.4.5 (mingw-vista special r3) C++ standard library: GNU libstdc++ version 20051201 Boost version : 1_34_1 SQLite version : 3.6.16 (compiled against 3.6.16) Lua version : Lua 5.1 PCRE version: 7.8 2008-09-05 (compiled against 7.8) Botan version : 1.8.4 (compiled against 1.8.4) Changes since base revision: format_version 1 new_manifest [a4583b2d0cae8cb6889b8701543aeb4efc7e1554] old_revision [a19f8b2017c81c3c6c8b2bb3247f865f6ed4e5a9] 2009-09-21 23:52:12,52 C:\tmp\mtn\mtn-cat-bug $ mtn -d mtn.mtn db init 2009-09-21 23:52:12,74 C:\tmp\mtn\mtn-cat-bug $ mtn -d mtn.mtn setup . -b mtn.bug.cat 2009-09-21 23:52:12,79 C:\tmp\mtn\mtn-cat-bug $ echo x 1example.txt 2009-09-21 23:52:12,81 C:\tmp\mtn\mtn-cat-bug $ mtn add example.txt mtn: adding example.txt to workspace manifest 2009-09-21 23:52:12,85 C:\tmp\mtn\mtn-cat-bug $ mtn ci -m Added new file. mtn: beginning commit on branch 'mtn.bug.cat' mtn: committed revision 3b2dcf8f04ccf68ef2f1959978514f12f32409d7 2009-09-21 23:52:13,21 C:\tmp\mtn\mtn-cat-bug $ mtn cat -r h: example.txt 1example-check.txt mtn: expanding selection 'h:' mtn: expanded to '3b2dcf8f04ccf68ef2f1959978514f12f32409d7' 2009-09-21 23:52:13,26 C:\tmp\mtn\mtn-cat-bug $ xxd -g8 example.txt 000: 780d0a x.. 2009-09-21 23:52:13,27 C:\tmp\mtn\mtn-cat-bug $ xxd -g8 example-check.txt 000: 780d0d0a x... Why the 0x0d (\r, CR, etc) gets doubled? PS: Running mtn cat --debug doesn't show anything interesting. Cheers, -- Marcin W. Dabrowski ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: [ANN] monotone 0.44 released
Thomas Keller wrote: monotone 0.44 was released today. Two quickies: http://monotone.ca/downloads/0.44/monotone-0.44-setup.exe - 404 Not Found http://monotone.ca/downloads/0.44/mtn.exe - 403 Access Denied Cheers, -- mwd ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Size of Win32 monotone binary.
Hi. Is there any rationale behind the fact that Win32 version setup is ~69 MB, and the mtn.exe binary is not stripped? Previous builds came without the debug symbols and were about 7 MB in size. And now... this is huge! :) Cheers, -- `-:[ mail: marcin.dabrowski-at-twine,pl ]-++-[ eccentrica.eu ]:-. .-:[ ,,Love is the law. Love under will.'' Aleister Crowley ]:-' ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: [ANN] monotone 0.44 released
http://monotone.ca/downloads/0.44/monotone-0.44-setup.exe - 404 Not Found http://monotone.ca/downloads/0.44/mtn.exe - 403 Access Denied Fixed, thanks. Mmm... Not so easy, unfortunately. The binary is not the setup, but unstripped monotone executable. It doesn't work, because the libidn-11.dll and libpcre-0.dll are missing. Fortunately enough I managed to download 0.43 setup, extract the missing libraries from there, stripped the 0.44 binary with MinGW strip, and... C:\usr\tmpmtn44s version --full monotone 0.44 (base revision: unknown) Running on : Windows NT/2000/XP/2003 (5.1, build 2600, Service Pack 3) on ia32 (level 6, rev 3846) C++ compiler: GNU C++ version 3.4.2 (mingw-special) C++ standard library: GNU libstdc++ version 20040907 Boost version : 1_33_1 SQLite version : 3.6.10 (compiled against 3.6.10) Lua version : Lua 5.1 PCRE version: 7.8 2008-09-05 (compiled against 7.8) Botan version : 1.8.0 (compiled against 1.8.0) Changes since base revision: unknown The question why the Win32 binary comes unstripped still stands. PS: Pushing stripped binary thru UPX gives 2.3 MB resulting exe. Comparing that to 71 MB original... Ouch! :D Cheers, -- Marcin ___ 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. Can you reproduce what the OP reported? Unfortunately no (and yes ... see the end) +1 from here. And maybe some additional comment. I'm having this behaviour on 0.41 as well, and in every situation involving Ctrl-C. Example: C:\tmp\mtnmtn log C:\usr\bin\mtn.exe: fatal: memory access violation this is almost certainly a bug in monotone. please send this error message, the output of 'C:\usr\bin\mtn.exe version --full', and a description of what you were doing to monotone-devel@nongnu.org And another: ... Date: 2009-01-07T13:38:11 Branch: head Added files: foo.txtC:\usr\bin\mtn.exe: fatal: undocumented exception this is almost certainly a bug in monotone. please send this error message, the output of 'C:\usr\bin\mtn.exe version --full', and a description of what you were doing to monotone-devel@nongnu.org It happens in diff, log, ls... Just in every command with long output. Running with --debug shows in the middle of the log: mtn: binding 2 with value 'date' mtn: cert: signable text [d...@e3a9275f4d65c2f46b42c0d2999ac73f1aa5f5fa:MjAwOS0wMS0wN1QxMzo0NTo1OA==] mtn: checking 128-byte signature mtn: cert ok mtn: botan_pipe_cache.hh:41: invariant 'I(!pipe)' violated Does it look like possible bug hive? :) Rgds., -- Marcin W. Dabrowski ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] WARNING: ~/.monotone/keys CONSIDERED HARMFUL
Hi all. I was lurking from time to time in this thread, and... I also have an idea to help Monotone migrate from its current system to a PGP-like system: Internally Monotone would have to use the key fingerprint, there's no getting around that. Would it be ever possible to have an option to use external tools for signing certs? I.e. GnuPG signatures? That way we'd get some PK infrastructure for free. Just a thought, my mere 0.02€... (If it was already discussed, then sorry - consider this mail as nonexistent.) Best regards, -- Marcin W. Dąbrowski | mwd at twine,pl `Love is the Law, Law under Will.' - AC ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: resolving name conflicts; file suturing vs drop
Hi. I was lurking into this conversation, and while being only a user, and not a coder, and I don't get the internals, etc - I was thinking about how monotone could interact with the user when ncc will occur, and how it could be resolved. I attached a hypothethical output from a session with mtn, with some options and comments dropped in it (I hope it's readable enough). Just a mere 0.02€ - I hope it will be useful. An idea was kind-of treating nccs as in Git, where almost all conflicts are about content - but in the case of monotone we preserve history by suturing. And, as you can see, I'd like to have the conflicts resolved in workspace - there may be more changes needed to have the project in sane state. PS: Don't ask me about resurrections, graveyards, implementation, etc - I might not have the answers. Just foot for thought. :) Best regards, -- Marcin W. Dąbrowski $ mtn version monotone 0.40 (base revision: 5ccc279f9dea0444b47f03dd5291ecc985fcb7f6) $ mtn -d d db init $ mtn -d d setup . -b main $ echo blah blah $ mtn add blah mtn: adding blah to workspace manifest $ mtn ci -m add blank file, creating base revision mtn: beginning commit on branch 'main' mtn: committed revision c7a2360dbefaecd6e5c3529ba05f4ded68483ad4 $ echo bar1 bar $ echo safe1 safe1 $ mtn add foo bar safe1 mtn: adding bar to workspace manifest mtn: adding foo to workspace manifest mtn: adding safe1 to workspace manifest $ mtn ci -m add files on right side mtn: beginning commit on branch 'main' mtn: committed revision 8d79b71def0a26652bd1da2c66ac58d301238081 $ mtn tag h: right mtn: expanding selection 'h:' mtn: expanded to '8d79b71def0a26652bd1da2c66ac58d301238081' $ mtn up -r p: mtn: expanding selection 'p:' mtn: expanded to 'c7a2360dbefaecd6e5c3529ba05f4ded68483ad4' mtn: selected update target c7a2360dbefaecd6e5c3529ba05f4ded68483ad4 mtn: [left] fbfcae5b1be482198b127d10fd9b2b680719f6e3 mtn: [right] c7a2360dbefaecd6e5c3529ba05f4ded68483ad4 mtn: dropping safe1 mtn: dropping bar mtn: updated to base revision c7a2360dbefaecd6e5c3529ba05f4ded68483ad4 $ echo bar2 bar $ echo safe2 safe2 $ mtn add bar safe2 mtn: adding bar to workspace manifest mtn: adding safe2 to workspace manifest $ mtn ci -m add files on left side mtn: beginning commit on branch 'main' mtn: committed revision 01e80706407c1cfa6b1b5c7a88c7ceae493d1c32 mtn: note: this revision creates divergence mtn: note: you may (or may not) wish to run 'mtn merge' $ mtn merge mtn: 2 heads on branch 'main' mtn: [left] 01e80706407c1cfa6b1b5c7a88c7ceae493d1c32 mtn: [right] 8d79b71def0a26652bd1da2c66ac58d301238081 mtn: conflict: duplicate name 'bar' for the directory '' mtn: added as a new file on the left mtn: added as a new file on the right mtn: error: merge failed due to unresolved conflicts $ mtn merge_into_workspace t:right mtn: expanding selection 't:right' mtn: expanded to '8d79b71def0a26652bd1da2c66ac58d301238081' mtn: [left] 01e80706407c1cfa6b1b5c7a88c7ceae493d1c32 mtn: [right] 8d79b71def0a26652bd1da2c66ac58d301238081 mtn: conflict: duplicate name 'bar' for the directory '' mtn: added as a new file on the left mtn: added as a new file on the right mtn: error: merge failed due to unresolved conflicts mtn: try merge_into_workspace --interactive $ mtn merge_into_workspace t:left --interactive mtn: expanding selection 't:left' mtn: expanded to '8d79b71def0a26652bd1da2c66ac58d301238081' mtn: [left] 01e80706407c1cfa6b1b5c7a88c7ceae493d1c32 mtn: [right] 8d79b71def0a26652bd1da2c66ac58d301238081 mtn: conflict: duplicate name 'bar' for the directory '' mtn: added as a new file on the left mtn: added as a new file on the right mtn: use: [c]urrent, [m]erged, [e]dit; or rename: [l]eft - merged, [r]ight - workspace, [b]oth mtn% c mtn: suturing as 'bar' with content from workspace mtn% m mtn: suturing as 'bar' with content from 8d79b71def0a26652bd1da2c66ac58d301238081 mtn% e mtn: diffing as content conflict, runnig $VISUAL to resolve -- here, user edits the file, and after leaving editor... mtn: suturing as 'bar' using edited content mtn% l mtn: misuse: use 'l new_file_name' mtn% l bar-left mtn: renaming 'bar' from 8d79b71def0a26652bd1da2c66ac58d301238081 as 'bar-left' mtn: adding bar-left mtn% r mtn: misuse: use 'r new_file_name' mtn% r bar-current mtn: renaming 'bar' in workspace as 'bar-current' mtn adding bar mtn% b mtn: misuse: use 'b left_file_name right_file_name' mtn% b bar-left bar-right mtn: renaming 'bar' from 8d79b71def0a26652bd1da2c66ac58d301238081 as 'bar-left' mtn: adding bar-left mtn: renaming 'bar' in workspace as 'bar-current' mtn: modifying blah mtn: adding safe1 mtn: updated to result of merge mtn: [left] 01e80706407c1cfa6b1b5c7a88c7ceae493d1c32 mtn: [right] 8d79b71def0a26652bd1da2c66ac58d301238081 $ mtn ci -m merged mtn: beginning commit on branch 'main' mtn: committed revision 9701b3e8c7f49b2bf8878c4bb29c994ea2d85314 ___ Monotone-devel mailing list Monotone-devel@nongnu.org
[Monotone-devel] Re: Monotone update failures...
Hi. add a 2 file in the directory mtn add one of the files mtn commit --branch=new.branch mtn update -r h:branch mtn.EXE: warning: cannot drop non-empty directory 'include/internal' whatever added directory was I don't see anything weird here. Monotone works as expected. The diff between 'new.branch' and 'branch' orders to drop the directory added in 'new.branch', but there's a unmanaged file in it. So, it can't drop the dir - it's not empty... was going to further do... mtn add the_other_file probably would end up with some sort of non-content conflict... It would - on both branches a new dir with the same name was added. The solution is to add one more step: 1. Create new directory, let's call this 'new-dir'. 2. mtn add new-dir 3. mtn ci -m New dir in main branch.' 4. Now, you can add new files to that dir. On my installation the following works as a charm. :) mtn -d mtn.mtn db init mtn -d mtn.mtn setup . -b branch-1 mkdir dir-1 mtn add dir-1 mtn ci -m New dir in main branch echo empty dir-1\file-1 echo empty dir-1\file-2 mtn add dir-1\file-1 mtn ci -b branch-2 -m Creating new branch. mtn up -r h:branch-1 Regards, -- mwd ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: Personal/Project/MtnSummit Introduction
I thought that a small viewing application based on PHP couldn't be that much of a problem. I had that phase too, and began a little something... but being alone, and being redundant, and having little precious free time, I eventually abandoned it... Mmm... If you need a li'l hand for PHP coding - count me in. I'd also like to see a PHP frontend for monotone, so I could put my 0.03€ in it... Rgds., -- mwd ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] fatal: std::logic_error: roster_merge.cc:528: invariant 'I(left_name == right_name)' violated
So, I don't want titles, I'd like to see working implementation of n.v.m.win32_pipes instead. :))) Uh.. I didn't ever care about that branch so far... The wiki doesn't know anything about it either. What's that branch about? See this message from the 'Sync Issue' thread: http://permalink.gmane.org/gmane.comp.version-control.monotone.devel/13988 I don't know the details, but the rev: 247bd4f73f994e0c... worried me a little, since I did a lot of file: wrangling recently. Stephen said it's broken, and the answer is somewhere in the win32_pipes branch. Well, I guess I must transfer myself to a proper OS some time in the future. :D Rgds., -- mwd ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] fatal: std::logic_error: roster_merge.cc:528: invariant 'I(left_name == right_name)' violated
Hi. Today I was playing with monotone 0.39 a bit, and by a mistake I've triggered 'something' - maybe a bug, at least monotone says so. mtn: propagating branch-b - branch-c mtn: [left] ef51f597662dc7f339d4bf38dcbde34f6f08ce33 mtn: [right] 4d781a16a76b290dd997f569783f4f9f2e79e28a mtn: fatal: std::logic_error: roster_merge.cc:528: invariant 'I(left_name == right_name)' violated mtn: this is almost certainly a bug in monotone. mtn: please send this error message, the output of 'mtn version --full', mtn: and a description of what you were doing to [EMAIL PROTECTED] Since picture tells more than words I won't describe exactly what I was doing. Instead I've made a test case in form of batch file, and added output from running this batch on my machine (mtn database, files, etc). All this is zipped, and availabe here: http://twine.pl/tmp/mtn-roster-merge-bug.zip (20 KiB) Outlining the case I can say the following: - create a directory, commit to master branch - rename directory, commit to branch-a - on master, add a file to directory, commit to branch-b - on master, add the same file name, commit to branch-c - propagate branch-a branch-c - success - propagate branch-b branch-c - failure The question is - why monotone won't say there's a conflict? Best regards, -- `-:[ Marcin W. Dąbrowski ]-=-[ Visit us at: http://twine.pl/ ]:-. .-:[ mail: marcin.dabrowski-at-twine,pl ]--[ hacking @ TWINE ]:-' `-:[ ,,Love is the law. Love under will.'' Aleister Crowley ]:-. .-:[ pgp fp: Erm, no valid GPG/PGP keys found at the moment. ]:-' ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Sync Issue
Hi. I've noticed the following change via CIA: http://viewmtn.angrygoats.net/all/revision/info/247bd4f73f994e0cebe3150d5a8322e26a6c6876 I'm using 'file:' on Win32, and it works just right for me. The fact that it is to be disabled in next release worried me a bit. If that is what you are using, switch to Cygwin monotone, if only for those sync operations. That's what I use, and it works reliably. Why one should use two binaries of one app which should work the same on every platform? We should document the broken Win32 operations in the manual, and possibly disable them in the code. Documenting wrong behavious and describing possible workarounds is good. Fixing the bug is even better. But disabling the feature in the code is just like breaking the functionality - and this is bad thing... For example, recently I'm doing some cleanups in our repositories, and have to go thru the following steps: mtn db init -d project.db mtn setup . -b project/edge -d project.db mtn pull file:project-branch1.db project-devel-branch1 mtn pull file:adam-project.db [EMAIL PROTECTED]/project mtn pull file:docs.db docs-xml-project mtn add -R dev dm doc mtn ci -m Workspace merge - CM step 1. mtn merge_into_dir project-devel-branch1 project/edge branch-1 mtn merge_into_dir [EMAIL PROTECTED]/project project/edge src mtn merge_into_dir docs-xml-project project/edge docsrc mtn up Is there any other way to sync two separate databases on Win32 without the need for '-serve'? What's the problem with 'file:' and how can I help to fix it, and bring it back to Win32? Best regards, -- `-:[ Marcin `DomBal' Dąbrowski ][ Visit us: http://twine.pl/ ]:-. .-:[ mail: marcin.dabrowski-at-twine,pl ]--[ hacking @ TWINE ]:-' `-:[ ,,Love is the law. Love under will.'' Aleister Crowley ]:-. .-:[ pgp fp: Erm, no valid GPG/PGP keys found at the moment. ]:-' ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
