gmane.comp.version-control.monotone.devel

mtn ci failed on NetBSD

Masao Uebayashi — 2008-12-02T03:29:25

I got this when I did a first commit in a repository which I've just moved & restored. Masao --------8<--------8<--------8<--------8<--------8<--------8<--------8<--------8< Current work set: 4 items ----- begin 'system_flavour' (in virtual void sanity::initialize(int, char**, const char*), at sanity.cc:75) NetBSD 4.99.61 NetBSD 4.99.61 (GENERIC) #7: Fri Apr 25 17:54:22 JST 2008 uebayasi< at >pushup.iij.ad.jp:/src/netbsd/obj/HEAD/i386/sys/arch/i386/compile/GENERIC i386 ----- end 'system_flavour' (in virtual void sanity::initialize(int, char**, const char*), at sanity.cc:75) ----- begin 'cmdline_string' (in virtual void sanity::initialize(int, char**, const char*), at sanity.cc:89) 'mtn', 'ci', '-m', 'Sync with HEAD.' ----- end 'cmdline_string' (in virtual void sanity::initialize(int, char**, const char*), at sanity.cc:89) ----- begin 'string(lc_all)' (in virtual void sanity::initialize(int, char**, const char*), at sanity.cc:94) C ----- end 'string(lc_all)' (in virtual void sanity::initialize(int, char**, const char*), at sanity.cc:94) ----- begin 'full_version_string' (in virtual void mtn_sanity::initialize(int, char**, const char*), at mtn-sanity.cc:23) monotone 0.41 (base revision: 9b264ec9247ce99cd1fdc5293e869c1a60b01c4c) Running on : NetBSD 4.99.61 NetBSD 4.99.61 (GENERIC) #7: Fri Apr 25 17:54:22 JST 2008 uebayasi< at >pushup.iij.ad.jp:/src/netbsd/obj/HEAD/i386/sys/arch/i386/compile/GENERIC i386 C++ compiler : Unknown ISO C++ Compiler C++ standard library: Unknown ISO standard library Boost version : 1_36 Changes since base revision: unknown ----- end 'full_version_string' (in virtual void mtn_sanity::initialize(int, char**, const char*), at mtn-sanity.cc:23)

Botan license change (patch review plz)

Jack Lloyd — 2008-11-30T17:56:01

In April 2008 the license for botan changed slightly (details at http://lists.randombit.net/pipermail/botan-devel/2008-April/000527.html) This patch changes three files, AUTHORS and gzip.{cc,hh} For AUTHORS I just copied the (C) notice for botan to match the text in nvm's botan/license.txt (presumably AUTHORS just never got updated after the inital import of botan into nvm) For gzip, I changed the copyright to reflect the authors and actual in-the-legal-sense copyright holders of botan's zlib.{cpp,h} on which the gzip implementation is based. These are Peter J Jones (of Netxx fame) who wrote the bzip2 support for botan (actually the very first piece of contributed code for botan), which I later copied and modified for zlib. This does not AFAIK actually change anything, because (since 'The Botan Project' did not exist in any legal sense) the copyright was always actually owned by Peter and myself, so this just changes the files to more accurately reflect reality. I can check in if OK. -Jack # # old_revision [93e7e626c6ee8db33a21eabcfab00d97f1bed8c2] # # patch "AUTHORS" # from [8c659d7e4cc960a79bcf1ceb69866ef146d48a8e] # to [65ed4da856c8c7010c49103f997830621b167150] # # patch "gzip.cc" # from [72e05981fe6cc8aa932363eef6c187241a4bb31d] # to [79c4d397bacac790edf635cbc109e5d6bf34bb2f] # # patch "gzip.hh" # from [0b391725625531a7f5c73d372355fb71e00c2b27] # to [391f70c2e4678fcc34ce5bbcd848335f94de882f] # ============================================================ --- AUTHORS8c659d7e4cc960a79bcf1ceb69866ef146d48a8e +++ AUTHORS65ed4da856c8c7010c49103f997830621b167150 < at >< at > -429,7 +429,15 < at >< at > http://botan.randombit.net/. It is lice botan/thanks.txt. The Botan distribution may be retrieved from http://botan.randombit.net/. It is licensed under a BSD-like license: -# Copyright (C) 1999-2006 The Botan Project. All rights reserved. +# Copyright (C) 1999-2008 Jack Lloyd +# 2001 Peter J Jones +# 2004-2007 Justin Karneges +# 2005 Matthew Gregan +# 2005-2006 Matt Johnston +# 2006 Luca Piccarreta +# 2007 Yves Jerschow +# 2007-2008 FlexSecure GmbH +# 2007-2008 Falko Strenzke # # Redistribution and use in source and binary forms, for any use, # with or without modification, is permitted provided that the ============================================================ --- gzip.cc72e05981fe6cc8aa932363eef6c187241a4bb31d +++ gzip.cc79c4d397bacac790edf635cbc109e5d6bf34bb2f < at >< at > -1,6 +1,7 < at >< at > /************************************************* * Gzip Compressor Source File * -* (C) 1999-2004 The Botan Project * +* (C) 2001 Peter J Jones (pjones< at >pmade.org) * +* 2001-2004 Jack Lloyd * * * * Based on the comp_zlib module, modified * * by Matt Johnston. This is not a complete * ============================================================ --- gzip.hh0b391725625531a7f5c73d372355fb71e00c2b27 +++ gzip.hh391f70c2e4678fcc34ce5bbcd848335f94de882f < at >< at > -1,6 +1,7 < at >< at > /************************************************* * Gzip Compressor Header File * -* (C) 1999-2004 The Botan Project * +* (C) 2001 Peter J Jones (pjones< at >pmade.org) * +* 2001-2004 Jack Lloyd * *************************************************/ #ifndef BOTAN_EXT_GZIP_H__ _______________________________________________ Monotone-devel mailing list Monotone-devel< at >nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel

using monotone for a simple logging database

John Wright — 2008-11-29T00:42:02

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

Filesystem normalisation

Peter Stirling — 2008-11-29T05:44:56

Hi, I've written a small module (it's one 'public' function and some support functions to make it clearer as to what it's doing) that solves the 'mtn add apple Apple' on Mac OS X. It uses Mac OS system calls to do its work so it will will need to only be compiled and linked for that. I've not worked with autoconf etc so I don't know how to do that conditional compilation (I've made a small driver program to work on it). Since I don't know how to do that I've not been able to build monotone with it, and consequently can't make a monotone style unit-test, or a patch that can be applied. The idea is to have a function void plaform_fs_normalisation_hook( std::string & const in, std::string & out ) that can be called from args_to_paths() (cmd.hh:146 on nvm 93e7e626c6ee8db33a21eabcfab00d97f1bed8c2). After the hook is complete the 'out' parameter contains either a version of the filename as the filesystem stores it on disk, or it will be the same as 'in' (if an error occurs) I chose to punt because I don't know if it would be bad to call one of die macros in that context. filepath constructors in paths.cc could probably also call the hook (args_to_paths() eventually calls them), but they are also called by other bits of code, and as I can't run the test suite I can't tell if that would break anything. Currently there is an ifdef'd function for non-mac builds, and for linux it would probably continue to be a no-op, but I think code with the same purpose as mine could be written for windows (I could take a bash at it, but I've never done windows programming so someone more familiar might be better). If this code is eventually included in monotone, then it would be possible to identify 2 files in a manifest that will conflict on disk, and perhaps perform an automatic rename. Currently it is appears impossible to checkout a revision that has conflicting filenames. The update aborts when it notices that a file with the second filename already exists, leaving the workspace with a _MTN/ detached The extra linker arguments are '-framework CoreServices' _______________________________________________ Monotone-devel mailing list Monotone-devel< at >nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel

fatal: std::logic_error: paths.cc:728: invariant'I(!empty())' violated

Vaclav Haisman — 2008-11-28T11:01:10

Hi, I am getting this error when I try to do initial commit of my /usr/local/etc: 35::root:/usr/local/etc> mtn commit -m "Initial import." mtn: beginning commit on branch 'local.radlicka.amber2/usr/local/etc' mtn: fatal: std::logic_error: paths.cc:728: invariant 'I(!empty())' 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 monotone-devel< at >nongnu.org. mtn: wrote debugging log to /usr/local/etc/_MTN/debug mtn: if reporting a bug, please include this file -- VH beginning commit on branch 'local.radlicka.amber2/usr/local/etc' Current work set: 4 items ----- begin 'system_flavour' (in virtual void sanity::initialize(int, char**, const char*), at sanity.cc:75) FreeBSD 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Wed Oct 15 18:56:54 UTC 2008 root< at >amber2.local:/usr/obj/usr/src/sys/GENERIC i386 ----- end 'system_flavour' (in virtual void sanity::initialize(int, char**, const char*), at sanity.cc:75) ----- begin 'cmdline_string' (in virtual void sanity::initialize(int, char**, const char*), at sanity.cc:89) 'mtn', 'commit', '-m', 'Initial import.' ----- end 'cmdline_string' (in virtual void sanity::initialize(int, char**, const char*), at sanity.cc:89) ----- begin 'string(lc_all)' (in virtual void sanity::initialize(int, char**, const char*), at sanity.cc:94) en_US.UTF-8 ----- end 'string(lc_all)' (in virtual void sanity::initialize(int, char**, const char*), at sanity.cc:94) ----- begin 'full_version_string' (in virtual void mtn_sanity::initialize(int, char**, const char*), at mtn-sanity.cc:23) monotone 0.41 (base revision: 9b264ec9247ce99cd1fdc5293e869c1a60b01c4c) Running on : FreeBSD 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Wed Oct 15 18:56:54 UTC 2008 root< at >amber2.local:/usr/obj/usr/src/sys/GENERIC i386 C++ compiler : GNU C++ version 4.2.1 20070719 [FreeBSD] C++ standard library: GNU libstdc++ version 20070719 Boost version : 1_34_1 Changes since base revision: unknown ----- end 'full_version_string' (in virtual void mtn_sanity::initialize(int, char**, const char*), at mtn-sanity.cc:23) monotone 0.41 (base revision: 9b264ec9247ce99cd1fdc5293e869c1a60b01c4c) Running on : FreeBSD 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Wed Oct 15 18:56:54 UTC 2008 root< at >amber2.local:/usr/obj/usr/src/sys/GENERIC i386 C++ compiler : GNU C++ version 4.2.1 20070719 [FreeBSD] C++ standard library: GNU libstdc++ version 20070719 Boost version : 1_34_1 Changes since base revision: unknown _______________________________________________ Monotone-devel mailing list Monotone-devel< at >nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel

Monotone Mini Summit: 2009-01-18 - 2009-01-19

Matthew A. Nicholson — 2008-11-25T18:00:36

Ok, No one strongly objected to the January 18 and 19, 2009 time frame, so let's go with that. We should generate a list of things to work on so that we have some direction once the mini-summit rolls around. I made a list on IRC recently, but I have since forgotten it. Either way, this is what I have so far. * Finish wiki migration and reorganization. I think we should spend some more time discussing how we will organize the new wiki. * Reorganize QuickieTasks and make it into a "Tasks" section of the wiki. The idea here is to give people with time and skills a direction to move towards. Ideally this new section would contain implementation ideas for all of the features we discuss on the mailing list. For an example, see: http://mtn-wiki.1erlei.de/wiki/PartialPull/ Please add your ideas to this list.

question about multiple syncs

Hugo Cornelis — 2008-11-22T00:33:53

I am working on the same project on 4 different PCs. This means a lot of sync operations between the repositories on the different PCs. So I have automated these frequent syncs using a perl script. The problem now, is that I am often loosing track about what was synchronized from where. What is the most easy way to add a cert to the repository to keep track of the original PCs where the commit was made ? What is the most easy way to add certs to the repository that flags a particular revision as being synchronized to a destination repository ? Is it possible to do this over Lua hooks ? Performance concerns ? Thanks, Hugo -- Hugo Cornelis Ph.D. Neurospaces Project Architect http://www.neurospaces.org/ Research Imaging Center University of Texas Health Science Center at San Antonio 7703 Floyd Curl Drive San Antonio, TX 78284-6240 Phone: 210 567 8112 Fax: 210 567 8152

monotone-0.41 compile failure withglibc(disabled-nls)

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

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

weird monotone behavior

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

Hi, I am using monotone 0.40 statically linked, downloaded from the monotone website on a redhat enterprise server 5. I encountered the following problem: I have a project that uses a database ~/neurospaces_project/MTN/installer.mtn I pulled an external database of the same project to ~/neurospaces_project/MTN/neurospaces-developer.mtn Changed the options files in a workspace, then did the things below. In a summary, after changing the option file, asking for a log overwrites the options file and makes it invalid. Changing back to the original database did not help. Not sure if I am doing something wrong, but monotone making the options file invalid makes me feel uncomfortable :( [19:46] (0,2) 0 $ cat _MTN/options database "/local_home/hugo/neurospaces_project/MTN/neurospaces-developer.mtn branch "0" [19:46] (0,2) 0 $ mtn log --debug mtn: searching for '_MTN' directory with root '/' mtn: working root is '/local_home/hugo/neurospaces_project/installer/source/snapshots/0' mtn: initial relative path is '' mtn: skipping nonexistent rcfile '/local_home/hugo/.monotone/monotonerc' mtn: skipping nonexistent rcfile '_MTN/monotonerc' mtn: searching for '_MTN' directory with root '/' mtn: working root is '/local_home/hugo/neurospaces_project/installer/source/snapshots/0' mtn: initial relative path is '' mtn: skipping nonexistent rcfile '/local_home/hugo/.monotone/monotonerc' mtn: skipping nonexistent rcfile '_MTN/monotonerc' mtn: local dump path is _MTN/debug mtn: setting dump path to /local_home/hugo/neurospaces_project/installer/source/snapshots/0/_MTN/debug mtn: loading lua hook note_mtn_startup mtn: executing command 'log' mtn: options path is _MTN/options mtn: branch name is '' mtn: options path is _MTN/options mtn: writing _MTN/options via temp _MTN/mty0dn8e.tmp mtn: revision path is _MTN/revision mtn: database.cc:3637: usage constraint 'N(false)' 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: Linux 2.6.18-53.1.19.el5 #1 SMP Tue Apr 22 03:01:13 EDT 2008 i686 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', 'log', '--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: en_US.UTF-8 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.40 (base revision: 5ccc279f9dea0444b47f03dd5291ecc985fcb7f6) mtn: Running on : Linux 2.6.18-53.1.19.el5 #1 SMP Tue Apr 22 03:01:13 EDT 2008 i686 mtn: C++ compiler : GNU C++ version 4.2.3 (Debian 4.2.3-3) mtn: C++ standard library: GNU libstdc++ version 20080322 mtn: Boost version : 1_34_1 mtn: Changes since base revision: mtn: unknown mtn: ----- end 'full_version_string' (in virtual void mtn_sanity::initialize(int, char**, const char*), at mtn-sanity.cc:23) mtn: statement cache statistics mtn: prepared 1 statements mtn: 0 executions of SELECT height FROM heights WHERE revision = ? mtn: misuse: database /local_home/hugo/neurospaces_project/MTN/neurospaces-developer.mtn mtn: misuse: branch does not exist [19:46] (0,2) 0 $ cat _MTN/options database "/local_home/hugo/neurospaces_project/MTN/neurospaces-developer.mtn branch " [19:46] (0,2) 0 $ If I do a fresh checkout in a temporary directory, everything seems fine and monotone behaves as expected without problem. [19:39] (0,2) tmp $ mtn co --db ~/neurospaces_project/MTN/neurospaces-developer.mtn -b 0 . Below the differences between the two directories. Seems that the 'new_manifest' line is the only significant difference. [19:58] (0,2) snapshots $ diff -ur tmp/ 0/ Only in 0/: config.log Only in 0/: config.status Only in 0/: Makefile diff -ur tmp/_MTN/options 0/_MTN/options --- tmp/_MTN/options 2008-11-15 19:58:01.000000000 -0600 +++ 0/_MTN/options 2008-11-15 19:51:02.000000000 -0600 < at >< at > -1,2 +1,2 < at >< at > -database "/local_home/hugo/neurospaces_project/MTN/neurospaces-developer.mtn" +database "/local_home/hugo/neurospaces_project/MTN/installer.mtn branch "0" diff -ur tmp/_MTN/revision 0/_MTN/revision --- tmp/_MTN/revision 2008-11-15 19:58:01.000000000 -0600 +++ 0/_MTN/revision 2008-11-04 11:01:09.000000000 -0600 < at >< at > -1,5 +1,5 < at >< at > format_version "1" -new_manifest [0000000000000000000000000000000000000004] +new_manifest [0000000000000000000000000000000000000001] old_revision [8e4f31b8c556911c4cbce9a52c789383947d7004] Hugo -- Hugo Cornelis Ph.D. Neurospaces Project Architect http://www.neurospaces.org/ Research Imaging Center University of Texas Health Science Center at San Antonio 7703 Floyd Curl Drive San Antonio, TX 78284-6240 Phone: 210 567 8112 Fax: 210 567 8152

heads up on nvm.stripped

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

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

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

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

It's possible to I() a server by sending invalid data, this actually happened here when merge_into_dir came out and not-up-to-the-minute versions thought the resulting revisions were bogus. I've just pushed a revision that makes the sanity macros look at a 'made_from' value, and throw bad_decode instead of their normal behavior if that value is set to made_from_network. ATOMIC and ENCODING types and revision_t have a member like this, and revision_t rev; rev.made_from = made_from_network; read_revision(garbage_data, rev); does actually throw bad_decode now for at least some kinds of garbage. I don't particularly like having the macros take a "hidden" argument like this, but I'm not sure what would be better. Having them call some function that you can declare in your class seems slightly cleaner, but that wouldn't allow things like made_from_t made_from(rev.made_from); I(rev.new_manifest == roster_manifest_id); (database::put_roster_for_revision) and keeping the function call inside the condition check (so arguments, especially the i18n_format arguments to N and E, are only evaluated when needed) prevents doing rev.I(rev.new_manifest == roster_manifest_id); . Does anyone know a way that would work better? Maybe we could pass the made_from explicitly, but then there are plenty of cases where you just don't have one. This also treats checks of function-local logic (I(false) on can't-get-here branches and such) the same as checks of data structures, so they also throw bad_decode if the data structure the function is on is marked as having come from the network. Do we want this? Is it worth avoiding this? It seems wrong, but fixing it would make it easier to use the wrong sanity macro and go back to throwing informative_failure on evil network data, and this isn't the easiest thing to write tests for...

Monotone Lua Hook for debian/changelog

Richard Laager — 2008-11-05T23:18:11

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

Error on monotone server

Mando Rodriguez — 2008-11-04T20:33:02

Hello, I have a monotone repository being hosted on a server. When doing a pull it will hang on the revisions count and sometimes require the user to terminate the process and attempt the pull 2 or 3 times before it complete successfully. Any idea what the problem could be? /:mtn-heccer: peer 129.111.255.255:43506 write failed in working state (error) mtn-heccer: accepted new client connection from 129.111.//255.255// : 43507 mtn-heccer: accepted new client connection from 129.111.//255.255// : 43508 mtn-heccer: peer 129.111.//255.255//:43507 read failed in working state (error) mtn-heccer: allowed anonymous read permission for '*' excluding '' mtn-heccer: finding items to synchronize: mtn-heccer: certificates | keys | revisions mtn-heccer: 2,861 | 2 | 916 mtn-heccer: peer 129.111.//255.255//:43508 processing finished, disconnecting/ -Mando

mtn buildbots

Markus Wanner — 2008-11-03T10:25:45

Hi again, besides the wiki, what's up with the buildbots? Most of those seem to be more redish than green, but mostly because the bots are down. Maybe that's a complaint towards buildbot itself, but I find it troublesome to distinguish between monotone failures and buildbot ones. Additionally, I'd like to start thinking about testing of nvm.stripped. For that, the bots would need to have the required libraries installed. Preferably with some comments about which versions of the libraries are installed. I'd like to add some bots with different library versions. Virtual ones and most probably all Debian, but none the less... Regards Markus Wanner

mtn wiki

Markus Wanner — 2008-11-03T10:18:45

Hi, the wiki has partly been migrated to another wiki system on the last summit. That's great, but the efforts somehow stalled. We are now left with a wiki marked as "do not edit" for already more than half a year. I only had a quick glance at the newish wiki branch, so I'd like to know from those in the know: * what's missing on the new ikiwiki? * what does it take to switch to the new one? * what does it give us, that the former one didn't? Regards Markus Wanner

nvm.resolve_conflicts ready to land on mainline

Stephen Leake — 2008-11-01T16:26:21

I believe nvm.resolve_conflicts is ready to land on mainline. The main feature on this branch is the new set of commands 'mtn conflicts *', that provide asynchronous conflict resolution, and an automated resolution for duplicate name conflicts. More on this below. In addition, there are some other small changes in behavior: paths.cc normalize_external_path no longer rejects "" as a path. This simplifies parsing the conflict resolution file, and makes other path handling more consistent. This was discussed here briefly, with no solid conclusion. Several file_path functions now take an argument "to_workspace_root" indicating that the path is relative to the workspace root, not the current directory. The --message or --message-file argument to merge and propagate specify the user part of the commit message; the current 'merge rev rev' or 'propagate from to' message is automatically prefixed. The prefix can be suppressed by --no-prefix. To understand the 'mnt conflicts' commands, I suggest you start by reading the info node Advanced Uses | Merge Conflicts, which has examples of using the conflicts commands to resolve content and duplicate name conflicts. Then move on the tests that start with 'resolve_conflicts'; they contain more examples. --

Removing database locks

Aarno Syvänen — 2008-10-29T09:47:54

Hi list, how can i simply remove monotone database lock ? I have manipulated the database only by myself, so this does not cause any problems. Aarno

changing behavior of --message and --message-filefor propagate

Stephen Leake — 2008-10-26T13:58:46

As part of implementing the resolve_conflicts commands, I'd like to change the behavior of --message and --message-file for propagate and merge. I'd like mtn to insert the current message: propagate from branch 'testbranch2' (head c606ed519e48f526bb130fd64fef712f795f0625) to branch 'testbranch1' (head 04fe9ed6642b2e258162f948934726a3085e473f) and then append the user-specified message. This allows a file-by-file description of changes for files modified by the conflict resolution process, similar to what we normally do for regular commits. However, this breaks the schema_migration_with_rosterify test, although not seriously. Part of that test compares the certs in two databases. One of the certs is the changelog for a propagate. Normally the two certs would be different because of different revids, but the test uses --message-file to specify one of the changelog certs to be the same as the other. My change above makes the certs no longer the same. One way to fix the schema_migration_with_rosterify test is to add code to ignore the changelog certs, but that's not simple to do; the current test just compares the entire output of 'automate certs', it doesn't parse it. Another fix is to not check the certs, but I suspect that's not a good idea. Another fix is to revert my change, and require the user to insert the "propagate from" message as part of their changelog. I don't think that's friendly. But since I'll normally be using Emacs DVC to do this, I could have DVC insert the "propagate from" part.

nvm.dates review

Zack Weinberg — 2008-10-26T01:19:03

diff -ruN S-vanilla/dates.hh S-dates/dates.hh --- S-vanilla/dates.hh2008-05-13 20:07:26.693813111 -0700 +++ S-dates/dates.hh2008-10-25 17:07:22.986962447 -0700 < at >< at > -19,31 +19,62 < at >< at > struct date_t { - // For the benefit of the --date option. - date_t() : d("") {} - bool valid() const { return d != ""; } + // initialize to an invalid date + date_t() : d(-1) {} Under what circumstances would one want a date_t with an invalid value? + // initialize from a unix timestamp + date_t(u64 d); I am not sure I like having this be a constructor instead of a factory function. I don't feel strongly about it, but it was more self-documenting the other way. Also, you still have the ::now() and ::from_string() factories, so now there's both factories and public constructors, which is confusing. Also, throughout, please make all your comments be complete sentences. + // initialize from multiple values "Initialize from broken-down time" would be clearer. That is the term used by the documentation of the C functions that deal in this representation. + date_t(int sec, int min, int hour, int day, int month, int year); Why doesn't this take milliseconds as well? ... + // Date comparison operators + bool operator <(struct date_t const & other) const No "struct", please (same for all the others) + // Our own gmtime function which converts the internal Unix epoch + // into a struct tm. + void gmtime(struct tm & tm) const; + void mktime(struct tm const & tm); Two problems here: first, you must not use struct tm for internal interchange. It is not as portable as one might think (yes, it's in C89, but BSD, SysV, and Windows all extended it in incompatible ways), and because of those extensions it is unsafe to fill one in by hand. You should use it only in the few cases where you have to use a function that takes or returns it, and you should strive to avoid doing that wherever possible. Fixing this is a requirement for merging back to n.v.m. Second, as a matter of clarity, please do not give any member function (of anything) the same unqualified name as a C library function! I was quite confused the first time I read the code. +date_t::date_t(int sec, int min, int hour, int day, int month, int year) +{ + // general validity checks + I((year >= 1970) && (year <= 9999)); Here and elsewhere - since you took out the buffer that would be too small in CE 10000, why are you still restricting the year to <= 9999? The year limit you should enforce is 2147483647, since all system structures for broken-down time that I am aware of (i.e. struct tm + the several similar things Windows has) use a 32-bit *signed* year field. The corresponding seconds-since-1970 count was in the old version of the file, although of course it'll need multiplying by 1000. + I((month >= 1) && (month <= 12)); + I((day >= 1) && (day <= 31)); + I((hour >= 0) && (hour < 24)); + I((min >= 0) && (min < 60)); + I((sec >= 0) && (sec < 60)); sec <= 60. Leap seconds do happen. +bool +date_t::valid() const +{ + // year 10000 limit + return d < u64_C(253402300800000); See above. + // This is the only place we rely on the system's time and date function + // which might operate on different epochs (i.e. 1980-01-01, as some + // Windows, old MacOS and VMS systems used). We immediately transform that + // to a struct tm representation, which is independent of the system's + // epoch. time_t t = time(0); struct tm b = *gmtime(&t); Since your endpoint format is a millisecond count, why do the expensive conversion to broken-down time and back? All you need to do is calculate and memoize the epoch offset used by this system, and then add that value to what you get back from time() and multiply by 1000. static s64 get_epoch_offset() { static s64 epoch_offset; static bool know_epoch_offset = false; if (know_epoch_offset) return epoch_offset; std::time_t epoch = 0; std::tm t = *std::gmtime(&epoch); // you should use the internal function that does this directly, of course; // and take care it doesn't bomb out if the offset is negative // (system epoch earlier than unix epoch) epoch_offset = date_t::from_broken_down_time(t.tm_sec, t.tm_min, t.tm_hour, t.tm_mday, t.tm_mon + 1, t.tm_year + 1900) .as_unix_epoch(); know_epoch_offset = true; return epoch_offset; } date_t date_t::now() { std::time_t t = std::time(0); date_t d; d.d = u64(t)*1000 + get_epoch_offset(); return d; } Easy! (Since the internal representation is in milliseconds, it would be nice to use gettimeofday() where available, but that's not urgent.) -unsigned int const MIN = 60; -unsigned int const HOUR = MIN * 60; -unsigned int const DAY = HOUR * 24; -unsigned int const YEAR = DAY * 365; -unsigned int const LEAP = DAY * 366; +u64 const SEC = u64_C(1000); +u64 const MIN = 60 * SEC; +u64 const HOUR = 60 * MIN; +u64 const DAY = 24 * HOUR; +u64 const YEAR = 365 * DAY; +u64 const LEAP = 366 * DAY; Why was this necessary? +string +date_t::as_iso_8601_extended() const +{ + struct tm tm; + gmtime(tm); + return (FL("%04u-%02u-%02uT%02u:%02u:%02u") + % (tm.tm_year + 1900) % (tm.tm_mon + 1) % tm.tm_mday + % tm.tm_hour % tm.tm_min % tm.tm_sec).str(); +} Another advantage of not using struct tm is, you could report the milliseconds too. +u64 +date_t::as_unix_epoch() const +{ + return d; +} This function should maybe have the word "millisecs" somewhere in its name. +void +date_t::gmtime(struct tm & tm) const { // these types hint to the compiler that narrowing divides are safe u64 yearbeg; - u32 year; + u16 year; u32 month; u32 day; - u32 secofday; + u32 msofday; u16 hour; - u16 secofhour; + u32 msofhour; u8 min; + u16 msofmin; u8 sec; + u16 msec; It might be more efficient to divide out the milliseconds at the very beginning. (And come to think of it, you could do seconds, minutes, and hours that way too, and deal in day counts for the rest of the code, which might be more comprehensible than how I wrote it originally.) + // ignore milliseconds, if present, or go back to the end of the date + // string to parse the digits for seconds. It's fractional seconds (you could have an arbitrary number); why ignore them, when you support millisecond precision? + // make sure we are still before year 10'000 Please stick to English notation for numbers (i.e. 10,000) -- but this check will be changing anyway... // more than four digits in the year - OK("120070301T184113", "12007-03-01T18:41:13"); + NO("120070301T184113"); // equals 12007-03-01T18:41:13 I expect this will be going away again after you take out the four-digit year check. zw

new test --no-workspace

Stephen Leake — 2008-10-25T22:08:25

The new test '--no-workspace' fails on MinGW. I'm not clear where the exact problem is; I get this message: unrecognized option '--no-workspace'error: incorrect self-invocation; -r There are other test directories whose names start with "_--"; I assume that's the accepted fix for this as well. I'll commit this change: mtn rename tests/--no-workspace tests/_--no-workspace --

compilation failure on Win32 MinGW

Stephen Leake — 2008-10-25T15:42:42

compile on Win32 MinGW is failing with: make[3]: *** No rule to make target `../monotone/botan/big_base.cpp', needed by `botan/lib3rdparty_a-big_base.o'. Stop. Is that a generated file, or did it just not get checked in?