Re: [Monotone-devel] hg2mtn 0.0.20070824
Thomas Keller schrieb: 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: Those are fields I simply don't care about - hence tmp.. mercurial doesn't seem to expose the interesting bits separately (and they exist in a single data structure in revlog, so it would likely be more expensive, too) # 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. That would mean I'd have to keep the manifests around (but with monotone's hashes, as mercurial gives me some other data), and copy the stuff appropriately. I'd also need to handle the case where the manifests don't exist (incremential update) For my purpose (35000 files per manifest, usually less than 10 patches), I think the brute force way I implemented is more efficient, esp. as access to file data in mercurial is very fast. I'm not sure at which point it would be more efficient to keep that cache (small repositories with lots of files changed in every revision?) And yeah, a little code cleanup and some explaining comments would be nice ;) That's what I'll do next. Together with some improv.. ermm.. initial work at a user interface. :-) Regards, Patrick Georgi ___ 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...
Ludovic == Ludovic Brenta [EMAIL PROTECTED] writes: Is this something I need to worry about, or should I just apply a bit of patience for a couple of weeks? Ludovic Patience. Boost 1.34.1-2 should migrate to testing in just two days, Ludovic as it no longer has release-critical bugs. What about Debian/stable? -- Brian May [EMAIL PROTECTED] ___ 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...
Brian May [EMAIL PROTECTED] writes: Ludovic == Ludovic Brenta [EMAIL PROTECTED] writes: Is this something I need to worry about, or should I just apply a bit of patience for a couple of weeks? Ludovic Patience. Boost 1.34.1-2 should migrate to testing in just two days, Ludovic as it no longer has release-critical bugs. What about Debian/stable? The next stable is not due before October 2008, so even more patience is required :) If you mean backporting to Etch, this really depends on a backport of boost to Etch. I have no idea about this. However there is a long-term plan for monotone to not require boost anymore. If and when it happens, that might make a backport easier. -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] merge bug? - silent data change
Hello, could you please look at http://mtn-host.prjek.net/viewmtn/ufs-trans/revision/info/951b0672754af7e3272775d548c04e3659089bd6 it can be obtained by mtn pull ufs-trans.mtn-host.prjek.net. look at the diff of sys/dev/wscons/wsdisplay_vcons.c (http://mtn-host.prjek.net/viewmtn/ufs-trans/revision/diff/6eb5489725a8c1b10bab48b8341fc5b3e57287a4/with/951b0672754af7e3272775d548c04e3659089bd6/sys/dev/wscons/wsdisplay_vcons.c) it is obviously nonsensical. I think that there is no reason to produce such a difference so it is apparently a merge bug. (comparing with the common ancestor 0795cc5f13f244bba69fd77457427d06026413e0, the file changed only on one side, 6eb5489725a8c1b10bab48b8341fc5b3e57287a4) two other people checked the merge independently and we always arrived at the same revision hash, so I think we can rule out some local corruption. any ideas? Pavel Cahyna ___ 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/24/07, Justin Patrin [EMAIL PROTECTED] wrote: 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. I thought I was clear that the problem was WITH inodeprints. I don't see what you propose would help me, because if any of it didn't work then monotone would be fully broken even for the basic of the users. The attached file is a monotone repository with an example of this behavior. It contains a test.dat and a test.c file that does a simple mmap processing on the test.dat file (I could have done other things but tried the replicate as close as possible what I'm doing in my application). Heres a use-case where it shows the issue: --- [EMAIL PROTECTED]:~/src/other/test_inodeprints$ ll total 328 -rwxr-xr-x 1 lucas lucas 8098 2007-08-25 16:32 a.out -rw-r--r-- 1 lucas lucas 319488 2007-08-25 16:31 m.db drwxr-xr-x 2 lucas lucas144 2007-08-25 16:32 _MTN -rw-r--r-- 1 lucas lucas 1377 2007-08-25 16:28 test.c -rw-r--r-- 1 lucas lucas 13 2007-08-25 16:05 test.dat [EMAIL PROTECTED]:~/src/other/test_inodeprints$ ll _MTN/ total 12 -rw-r--r-- 1 lucas lucas 2 2007-08-25 16:29 format -rw-r--r-- 1 lucas lucas 0 2007-08-25 16:31 log -rw-r--r-- 1 lucas lucas 109 2007-08-25 16:32 options -rw-r--r-- 1 lucas lucas 133 2007-08-25 16:31 revision [EMAIL PROTECTED]:~/src/other/test_inodeprints$ mtn refresh_inodeprints [EMAIL PROTECTED]:~/src/other/test_inodeprints$ ll _MTN/ total 16 -rw-r--r-- 1 lucas lucas 2 2007-08-25 16:29 format -rw-r--r-- 1 lucas lucas 151 2007-08-25 16:33 inodeprints -rw-r--r-- 1 lucas lucas 0 2007-08-25 16:31 log -rw-r--r-- 1 lucas lucas 109 2007-08-25 16:33 options -rw-r--r-- 1 lucas lucas 133 2007-08-25 16:31 revision [EMAIL PROTECTED]:~/src/other/test_inodeprints$ mtn st Current branch: test Changes against parent 5e14d3384e28dc55ff0e711c1ecfb485275d587c no changes [EMAIL PROTECTED]:~/src/other/test_inodeprints$ cat test.dat ABCD DEFG [EMAIL PROTECTED]:~/src/other/test_inodeprints$ ./a.out test.dat test.dat: Done (rc=0) [EMAIL PROTECTED]:~/src/other/test_inodeprints$ mtn st Current branch: test Changes against parent 5e14d3384e28dc55ff0e711c1ecfb485275d587c no changes [EMAIL PROTECTED]:~/src/other/test_inodeprints$ cat test.dat DEFA ABCG --- Off course that if I do a refresh_inodeprints or remove the inodeprints file it will work, but that is not the point. My point is I'm trying to understand if this is a bug or a work as designed kind of thing. Regards, ~Nuno Lucas -- Justin Patrin m.db.bz2 Description: BZip2 compressed data ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: Monotone fails to detect certain changes in files
On Fri, Aug 24, 2007 at 05:03:15AM +0100, Nuno Lucas wrote: 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. Does your small utility use msync()? Apparently without msync, file modification change is supposed to be updated at some point in the future, which might be after monotone checks it. Pavel ___ 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
In message [EMAIL PROTECTED] on Sat, 25 Aug 2007 16:49:37 +0100, Nuno Lucas [EMAIL PROTECTED] said: ntlucas Off course that if I do a refresh_inodeprints or remove the ntlucas inodeprints file it will work, but that is not the point. ntlucas ntlucas My point is I'm trying to understand if this is a bug or a ntlucas work as designed kind of thing. I would say it's work by design. The inodeprint for each file is a hash of the concatenation of ctime, mtime, mode, inode number, device number, uid, gid and size. If none of those change and only content, then inodeprints isn't for you, as your way of changing the files REQUIRES checking the contents, making inodeprints a moot feature. Cheers, Richard -- 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
Fwd: [Monotone-devel] Re: Monotone fails to detect certain changes in files
[didn't noticed this ML does't like the reply-to thing] -- Forwarded message -- From: Nuno Lucas [EMAIL PROTECTED] Date: Aug 26, 2007 4:31 AM Subject: Re: [Monotone-devel] Re: Monotone fails to detect certain changes in files To: Pavel Cahyna [EMAIL PROTECTED] On 8/25/07, Pavel Cahyna [EMAIL PROTECTED] wrote: On Fri, Aug 24, 2007 at 05:03:15AM +0100, Nuno Lucas wrote: 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. Does your small utility use msync()? Apparently without msync, file modification change is supposed to be updated at some point in the future, which might be after monotone checks it. No, it doesn't. It releases the resources properly (instead of simply exit), but doesn't do any msync. I replayed my test.c sample with an explicit msync(addr,len,MS_SYNC) at the end, but got the same behavior as before. Looking more throughly at the [f]stat manpage(s) (including the POSIX manpages), noticed the case without msync is unspecified. It is specified what happens with atime if the noatime is not used, but nothing is said about what happens if noatime is used: - Not all of the Linux filesystems implement all of the time fields. Some file system types allow mounting in such a way that file accesses do not cause an update of the st_atime field. (See 'noatime' in mount(8).) - Ok, this is expected behavior. - The field st_atime is changed by file accesses, e.g. by execve(2), mknod(2), pipe(2), utime(2) and read(2) (of more than zero bytes). Other routines, like mmap(2), may or may not update st_atime. The field st_mtime is changed by file modifications, e.g. by mknod(2), truncate(2), utime(2) and write(2) (of more than zero bytes). Moreover, st_mtime of a directory is changed by the creation or deletion of files in that directory. The st_mtime field is not changed for changes in owner, group, hard link count, or mode. The field st_ctime is changed by writing or by setting inode information (i.e., owner, group, link count, mode, etc.). - Notice how they say atime can be ignored on mmap uses, but don't specify what hapens when mmap is used with mtime and ctime. The equivalent POSIX manpages do the same, so it almost seems it was made on purpose just for this case. Interestingly enough, my tests with msync showed that Linux is broken (relative to POSIX) in this case because, even if noatime is set, it should have set mtime if there was a write. But it may be a filesystem/driver thing, not a general Linux issue (only tested on a reiserfs v3 partition). In a nutshell, it almost seems like the absence of a specification for this case explains it, although at the same time it doesn't when one uses msync (shows a POSIX violation) . Best regards, ~Nuno Lucas Pavel ___ 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/25/07, Richard Levitte [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED] on Sat, 25 Aug 2007 16:49:37 +0100, Nuno Lucas [EMAIL PROTECTED] said: ntlucas Off course that if I do a refresh_inodeprints or remove the ntlucas inodeprints file it will work, but that is not the point. ntlucas ntlucas My point is I'm trying to understand if this is a bug or a ntlucas work as designed kind of thing. I would say it's work by design. The inodeprint for each file is a hash of the concatenation of ctime, mtime, mode, inode number, device number, uid, gid and size. If none of those change and only content, then inodeprints isn't for you, as your way of changing the files REQUIRES checking the contents, making inodeprints a moot feature. Ok, it makes sense and I can live with that. At the same time, as I noticed on my previous answer to Pavel, it seems if I do a msync at the end Linux should update the file mtime, even if atime is not. So that shows a POSIX workaround that can't be used on Linux. Well, that's life, and only bothered the list with this because I feel it's a behavior that other people can notice later and this way becomes documented. Best regards, ~Nuno Lucas Cheers, Richard -- 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
