gmane.comp.version-control.monotone.devel

Monotone Crash

Ulf Ochsenfahrt — 2008-12-03T09:21:19

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

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

Matthew Nicholson — 2008-12-03T04:13:46

Yes that is correct, my mistake.

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

Matthew Nicholson — 2008-12-03T04:13:07

I have started a wiki page[1] with these ideas. Feel free to edit that page, and please also continue to discuss ideas on the mailing list. I would like to have a solid list of things to work on by January 12th, and then flesh those out for a week until the 17th so that we have a solid agenda for our virtual summit. [1] http://mtn-wiki.1erlei.de/wiki/MtnSummit/2009

Re: Filesystem normalisation

Nathaniel Smith — 2008-12-02T15:08:56

On Tue, Dec 2, 2008 at 4:16 AM, Stephen Leake stephe-leake.org> wrote: I'm not sure it exists either, but for the question you raised it doesn't matter -- if it exists we should call it, if it doesn't then there's nothing sensible that a lua hook could do anyway. Enforcing project specific rules is a whole other issue; this is just about interacting correctly with the filesystem...

Re: Filesystem normalisation

Stephen Leake — 2008-12-02T13:25:42

Actually, I take this back. If the goal is to prevent checking in files that violate the project naming convention (ie, unique on Windows), then a developer working on Linux must be subject to the Windows filename rules. That requires a user hook. Hmm. I guess it could be a global option that chooses from a predefined set of rules for Linux, Windows, MAC OSX. But a hook lets projects define other conventions, such as "all lowercase except Makefiles" (my current convention, not very well enforced).

Re: Filesystem normalisation

Stephen Leake — 2008-12-02T12:16:24

This is true; if there exists a function that returns an existing filename that matches a candidate, preserving case, no matter what the actual filesystem is, then that's all we need. I'm pessimistic that such a function exists in Windows, but I admit I haven't looked or tested.

Re: Filesystem normalisation

Zack Weinberg — 2008-12-02T07:18:30

No comment on anything else right now, but ... On Mon, Dec 1, 2008 at 10:38 PM, Stephen Leake stephe-leake.org> wrote: ... this really shouldn't be necessary. If the filename validation logic (however it works, and whatever the necessary division of labor is between monotone and the OS) is properly designed, it will be aware of different file systems and do the right thing. The hook you suggest is asking users to fix our bugs for us. zw

Re: Filesystem normalisation

Stephen Leake — 2008-12-02T06:38:35

I think I see the problem. In mtn, the term 'hook' means "a function whose body is provided by the user as Lua code". In addition, all hooks have a default Lua implementation. However, you are using 'hook' to mean "a function with platform-specific behavior". And there is code in fs.cc that is specific to MACOSX. I'm not clear what that code does (since I don't have a MAC); does it return a matching file name that currently exists? Does it preserve case, or always return lowercase or uppercase? In order to accomodate different filesystems on one platform (via NFS or some other mechanism), I think this function needs to be a user-provided Lua hook, with a default that works for Win32, Linux, and MAC OSX native filesystems.

Re: mtn ci failed on NetBSD

Nathaniel Smith — 2008-12-02T04:16:02

Can you post the full --debug log?

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**

Re: Filesystem normalisation

Stephen Leake — 2008-12-01T14:38:16

Ok. Yes, there are case sensitivity issues on Windows. As I understand it, your patch provides a hook that lets a user function rewrite a file path. So the hook would have to handle that case. I didn't see the actual hook code in your attachment; did I miss it somewhere? Yes, sorry for the wrong name. Ah; on __APPLE__ it does nothing. But if you put the appropriate code there, would that solve your problem? That should be simpler than adding a hook. normalize_external_path is the inverse (approximately) of as_external. So it should contain the inverse path-conversion code for APPLE. Thanks for the clear example. I agree it would be _very_ nice if mtn gave some sort of error here. I gather your proposed hook would change "APPLE" to "apple" so the paths would collide, and mtn would say something like "'apple' already accounted for" on the second file. One way to make that happen is for mtn normalized paths to be all lowercase on case-insensitive file systems. However, I prefer case-insensitive bu

Re: Filesystem normalisation

Nathaniel Smith — 2008-12-01T10:10:25

This isn't about bad paths, just about figuring out which actual path is meant when a user gives us some string. As such, it doesn't actually belong in args_to_paths, but it does belong in file_path_from_external (or whatever the exact name is), which is the code that's actually responsible for taking user-provided strings and turning them into well-formed internal paths. (args_to_paths is just a thin wrapper around it.) There are other issues with filenames that collide on some systems and not on others, but this isn't about that in particular; even if we get better tools for handling such cases, we still want to prevent them from arising accidentally, and that's what this code is supposed to do. (Plus you can't solve the hard problems without the primitive "hey OS what path do *you* think this refers to?" operation, and so this gets us closer by giving us code to that on at least OS X.) By all means, Peter, send a patch.

Re: Filesystem normalisation

Derek Scherger — 2008-12-01T04:18:24

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

Re: Filesystem normalisation

Peter Stirling — 2008-12-01T01:14:13

On 29 Nov 2008, at 11:48 am, Stephen Leake wrote: It is insensitive by default, and a number of programs won't work if you set it to case-sensitive, so the vast majority of people will not set it that way. According to http://www.venge.net/mtn-wiki/CaseInsensitiveFilesystems case insensitivity is also an issue on windows. Also, HFS+ stores files in NFD utf-16 (it makes case insensitive sorting/searching much quicker), this means that you will also have issues with filenames entered as precomposed unicode (and my patch covers that case too). grep -r to_external . returns nothing, I assume that you meant string any_path::as_external() const { #ifdef __APPLE__ // on OS X paths for the filesystem/kernel are UTF-8 encoded, regardless of // locale. return data; #else // on normal systems we actually have some work to do, alas. // not much, though, because utf8_to_system_string does all the hard work. // it is carefully optimized. do not screw it up. external out; utf8_to_sy

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

Vaclav Haisman — 2008-11-30T23:09:42

Thanks. That fixed it for me. I actually have a key but I forgot to import it into the root account. -- VH

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

Vaclav Haisman — 2008-11-30T21:17:22

Attached. -- VH mtn: searching for '_MTN' directory with root '/' mtn: working root is '/usr/local/etc' mtn: initial relative path is '' mtn: skipping nonexistent rcfile '/root/.monotone/monotonerc' mtn: skipping nonexistent rcfile '_MTN/monotonerc' mtn: searching for '_MTN' directory with root '/' mtn: working root is '/usr/local/etc' mtn: initial relative path is '' mtn: skipping nonexistent rcfile '/root/.monotone/monotonerc' mtn: skipping nonexistent rcfile '_MTN/monotonerc' mtn: loading lua hook get_default_command_options mtn: local dump path is _MTN/debug mtn: setting dump path to /usr/local/etc/_MTN/debug mtn: loading lua hook note_mtn_startup mtn: executing command 'commit' mtn: options path is _MTN/options mtn: branch name is 'local.radlicka.amber2/usr/local/etc' mtn: options path is _MTN/options mtn: writing _MTN/options via temp _MTN/mt7xns38.tmp mtn: revision path is _MTN/revision mtn: base roster has 0 entries mtn: revision path is _MTN/revision mtn: inodeprints path is _MTN/inodeprints mtn:

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

Timothy Brownawell — 2008-11-30T22:17:27

[...] [...] [...] You will have to run "mtn genkey", to give you a key for monotone to use to commit with. You'll have to either do this outside of the workspace (/usr/local/etc) or provide the --confdir or --keydir option. After this, you should be able to fix it by giving --confdir=/root/.monotone or --keydir=/root/.monotone/keys when you commit (unless you gave these to genkey, then you shouldn't need them). After doing this, there should be a line keydir "/root/.monotone/keys" in _MTN/options . Adding that line manually is another way to fix it. (Or you could use different values if you don't like the defaults.) What appears to be happening is that monotone doesn't realize that there isn't a keydir line in _MTN/options, and is trying to use this (missing) value instead of the default (this is the bug). The value never got written because that directory doesn't exist (don't want to save possibly invalid option values). It's created when a key is first saved, which can happen by means of "mtn genke

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

Timothy Brownawell — 2008-11-30T19:18:59

Could you try again with --debug and send us the output and the contents of your _MTN/options? Having a line 'database ""' in your _MTN/options could cause problems with older versions, but that's supposed to be fixed (or at least improved) in 0.41 .

Re: Error on monotone server

Timothy Brownawell — 2008-11-30T18:38:50

Which version of monotone is this (both server and client)? We did have a problem for a while where the connection would stall, but IIRC it was fixed a couple versions ago. Does this still happen for you when using 0.40 for both client and server?

Re: Botan license change (patch review plz)

Zack Weinberg — 2008-11-30T18:16:50

Yes, please apply. Thanks for being diligent about this sort of thing. zw On Sun, Nov 30, 2008 at 9:56 AM, Jack Lloyd randombit.net> wrote:

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_revis