Re: [Monotone-devel] Re: Windows version 0.36
J Decker wrote: > This really IS a problem will it be sorted out? Are you trying to use a single database for interactive work as well as the server process? If so, this never did work properly and is not currently supported. You must have separate databases for the server process and any "client" processes. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] hg2mtn 0.0.20070824
Patrick Georgi schrieb: > As it's one of my first large python project "from scratch", it's probably > full of no-nos of python design. Patches welcome and accepted! I'm a Python novice myself, so I can't give you much advice (despite I don't like "tmp"-named variables very much in any language ;). However, by skimming through your code I found this: # FIXME: handle renamed files ofctx = parentcontext.filectx(file) oldid = sha.new(ofctx.data()).hexdigest() This looks like you're hashing the old file contents for each patch you are going to feed into mtn, right? Wouldn't it be better to use some kind of cache here, since if you process the revisions forwardly, you should already know all the fileids from previous revisions, don't you? Maybe this could speed up the thing a bit more. And yeah, a little code cleanup and some explaining comments would be nice ;) Thomas. -- only dead fish swim with the stream: http://thomaskeller.biz/blog Am Anfang war das Wort: http://www.schäuble-muss-weg.de signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Small problem with the latest Debian changes...
On 8/24/07, Richard Levitte <[EMAIL PROTECTED]> wrote: > since debian/control was changed to require version 1.34.1-2 of the > boost libraries, my snapshots will not build on [testing], since the > boost libraries haven't come that far yet there. > > Is this something I need to worry about, or should I just apply a bit > of patience for a couple of weeks? You can safely lower the dependency when making the snapshots, but please don't put that on mainline or .debian-diff. The soname convention for Debian's packaged Boost libraries changed and we need to make sure the official packages are consistently built against the new convention. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Small problem with the latest Debian changes...
Richard Levitte <[EMAIL PROTECTED]> writes: > since debian/control was changed to require version 1.34.1-2 of the > boost libraries, my snapshots will not build on [testing], since the > boost libraries haven't come that far yet there. > > Is this something I need to worry about, or should I just apply a bit > of patience for a couple of weeks? Patience. Boost 1.34.1-2 should migrate to testing in just two days, as it no longer has release-critical bugs. -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: Windows version 0.36
This really IS a problem will it be sorted out? On 8/23/07, J Decker <[EMAIL PROTECTED]> wrote: > > I recently updated to this. I occasionally serve my database so i can > pull/push to my virtual machines on the same system. The current version ( > 0.35 did not do this) ends up leaving the database locked after the client > connects to sync.(I cannot just use the database anymore without closing > the serving process) > > Jim > ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Small problem with the latest Debian changes...
In message <[EMAIL PROTECTED]> on Sat, 25 Aug 2007 00:41:01 +0200, Ludovic Brenta <[EMAIL PROTECTED]> said: ludovic> Patience. Boost 1.34.1-2 should migrate to testing in just ludovic> two days, as it no longer has release-critical bugs. Thanks. I think I can do two days. I've got other things to deal with over the weekend anyway, so I guess this should the opportune moment NOT to have an excuse away from those ;-). Cheers, Richard - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ "When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up." -- C.S. Lewis ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Small problem with the latest Debian changes...
Hi, since debian/control was changed to require version 1.34.1-2 of the boost libraries, my snapshots will not build on [testing], since the boost libraries haven't come that far yet there. Is this something I need to worry about, or should I just apply a bit of patience for a couple of weeks? Cheers, Richard - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ "When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up." -- C.S. Lewis ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] hg2mtn 0.0.20070824
Hi, I hereby do the first public release of hg2mtn, an importer of hg repositories into monotone. It's licensed under GPL (v2+) as it makes use of other GPL components. I first tried to write something general based on an implementation of the git-fast-import interface for mtn, but that wasn't such a good idea as it basically results in two lossy steps: whatever-to-git-semantics and git-semantics-to-mtn, so I wrote a direct hg2mtn importer now. At this time, it lacks all the usability bits (like getopt parsing, a tarball release, or sane user feedback). It requires the automate stuff of tracvc. It's probably easiest to just have the whole tracvc tree in the PYTHONPATH for now. It also requires an installation of mercurial (it basically uses its code to read the repo) The location of the hg repository, the mtn repository and the branch where all the hg stuff should end up are set in some variables in the source. I also recommend adding a transaction guard to automate stdio because mtn commits every single put_file, which leads to a massive slowdown (at least on some filesystems - on ZFS it's 4 minutes instead of 20 now) For now, it stops execution after 50 commits, you can restart and it will skip the existing revisions (that's partly a work around for the transaction guard - it really requires an "automate commit" command, so that at certain points the database state can be frozen, as otherwise all work is lost on ctrl-c). Export to mercurial shouldn't be too hard (the import keeps the hg revision as cert to every mtn revision), but that's beyond the scope of my work for now. Also missing (but on my TODO): - handling of hg tags - handling of whatever rename facility they have Some hg repos seem to contain merges that are invalid on monotone (revival of files in a merge that were killed on one side) - hg2mtn fails with an monotone invariant there. As it's one of my first large python project "from scratch", it's probably full of no-nos of python design. Patches welcome and accepted! Regards, Patrick Georgi hg2mtn.py Description: application/python ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Monotone fails to detect certain changes in files
On 8/23/07, Nuno Lucas <[EMAIL PROTECTED]> wrote: > It seems my use of monotone and mount options enters in conflict with > the inodeprints optimization: > > - > > [EMAIL PROTECTED]:~/prjs/etpos/data$ mtn st . > Current branch: etpos.master > Changes against parent a597159c0133529d4f4a17d053507de7f07bb0cd > addedfactory.bck/etetq/data/TODO.txt > patched factory.bck/etetq/data/jnlg/esp/304 > patched factory.bck/etetq/data/jnlg/esp/702 > patched factory.bck/etetq/data/jnlg/esp/703 > patched factory.bck/etetq/data/jnlg/por/304 > patched factory.bck/etetq/data/jnlg/por/702 > patched factory.bck/etetq/data/jnlg/por/703 > patched factory.bck/etetq/data/mnsg/esp/cmd > patched factory.bck/etetq/data/mnsg/por/cmd > [EMAIL PROTECTED]:~/prjs/etpos/data$ mtn refresh_inodeprints > [EMAIL PROTECTED]:~/prjs/etpos/data$ mtn st . > Current branch: etpos.master > Changes against parent a597159c0133529d4f4a17d053507de7f07bb0cd > addedfactory.bck/etetq/data/TODO.txt > patched factory.bck/etetq/data/fch/doc/esp/docp-1 > patched factory.bck/etetq/data/fch/doc/esp/docp-2 > patched factory.bck/etetq/data/fch/doc/esp/docu-1 > patched factory.bck/etetq/data/fch/doc/esp/docu-2 > patched factory.bck/etetq/data/fch/doc/esp/talp-1 > patched factory.bck/etetq/data/fch/doc/esp/talp-2 > patched factory.bck/etetq/data/fch/doc/esp/talu-1 > patched factory.bck/etetq/data/fch/doc/fra/docp-1 > patched factory.bck/etetq/data/fch/doc/fra/docp-2 > patched factory.bck/etetq/data/fch/doc/fra/docu-1 > patched factory.bck/etetq/data/fch/doc/fra/docu-2 > patched factory.bck/etetq/data/fch/doc/fra/talp-1 > patched factory.bck/etetq/data/fch/doc/fra/talp-2 > patched factory.bck/etetq/data/fch/doc/fra/talu-1 > patched factory.bck/etetq/data/fch/doc/por/docp-1 > patched factory.bck/etetq/data/fch/doc/por/docp-2 > patched factory.bck/etetq/data/fch/doc/por/docu-1 > patched factory.bck/etetq/data/fch/doc/por/docu-2 > patched factory.bck/etetq/data/fch/doc/por/talp-1 > patched factory.bck/etetq/data/fch/doc/por/talp-2 > patched factory.bck/etetq/data/fch/doc/por/talu-1 > patched factory.bck/etetq/data/jnlg/esp/304 > patched factory.bck/etetq/data/jnlg/esp/702 > patched factory.bck/etetq/data/jnlg/esp/703 > patched factory.bck/etetq/data/jnlg/por/304 > patched factory.bck/etetq/data/jnlg/por/702 > patched factory.bck/etetq/data/jnlg/por/703 > patched factory.bck/etetq/data/mnsg/esp/cmd > patched factory.bck/etetq/data/mnsg/por/cmd > [EMAIL PROTECTED]:~/prjs/etpos/data$ mtn --version > monotone 0.36 (base revision: e4bc808d89e029ce623f9e8f2b10c84006b83fb5) > [EMAIL PROTECTED]:~/prjs/etpos/data$ mount | grep home > /dev/sda3 on /home type reiserfs (rw,noatime) > [EMAIL PROTECTED]:~/prjs/etpos$ uname -a > Linux nilo 2.6.20-16-generic #2 SMP Thu Jun 7 20:19:32 UTC 2007 i686 GNU/Linux > > - > > I believe the problem is that I used a small data conversion program > that changed the files by mmaping them (it's a small utility to > convert files with a MS-DOS codepage to ISO-8859-1 and some few other > simple character table-based conversions), and it seems that use-case, > with the "noatime" mount option, doesn't get noticed. > > Not sure if it really is a bug or something I should expect because of > the way my system is setup and the way I work with the mmaped file. > Are you using inodeprints? Go to your workspace and try "rm _MTN/inodeprints" and see if it detects your changes. You would also try "mtn refresh_inodeprints". -- Justin Patrin ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
