[Monotone-devel] help-rewrite (was: Re: encapsulation branch)
On 20/04/2007, at 7:37 AM, Julio M. Merino Vidal wrote: Just FYI, I'm also messing with the way to define commands and subcommands, so I also have to look at how to define the automate ones. See the net.venge.monotone.help-rewrite branch (which currently builds but is severely broken). I've been giving the command interface some thought. In particular, I wanted to define some other convenience commands like "mtn pup" which does both a pull and an update. These could be done as shell scripts, but I'm also supporting some windows users and I don't want to write the scripts in multiple scripting languages, so... I was looking at transferring the command definitions to lua. The idea is that we can then play around with the interface, define aliases, define commands that are sequences of other commands, all in a neat, safe, cross-platform manner. I haven't gotten around to doing any coding on this yet... too much time making cars drive themselves... Be well, Will:-} ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] encapsulation branch
Markus Schiltknecht schrieb: > Hi, > > as you might have noticed, I've done some work in > nvm.experiment.encapsulation. Based on Zack's idea, I've removed the > app_state from lots of functions and objects. This has two reasons: > > - reducing the amount headers included > - allow for read only database functionality (which is enforced by the > compiler) I like the idea. One question though: if we look at certain system entities, like a database or a workspace as single entities, and no longer in terms of a global, single "app_state" object, would it be possible (in general) to make these exchangable easily? What I was thinking of here is automate stdio, which, once started, runs on exactly one single database / workspace, and this is determined during initialization. The basic problems here are a) one cannot load another database or workspace within one and the same stdio process (workspace is problematic because of path initialization AFAIR) b) if a) is not a real problem for many people because they like to start a separate process for every workspace / database anyways, one still does not know if the workspace or database is a valid one for the running monotone instance _until_ you trigger commands which use them. If a database or workspace is loaded deferred, i.e. with a separate automate command, it could explicitely fail if something is wrong, rather than implicit as it is now. Thomas. -- ICQ: 85945241 | SIP: 1-747-027-0392 | http://www.thomaskeller.biz > Guitone, a frontend for monotone: http://guitone.thomaskeller.biz > Music lyrics and more: http://musicmademe.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Error with version 0.34 on win32 running `mtn diff -r [FILE]`
Hopefully this doesn't go through twice, since I originally sent it with a massive debug file. The below is the command that triggered the error message, with the corresponding error message and the output of `mtn --full-version` The debug file is over 700kb, so I uploaded it here: http://pidgin.im/~datallah/mtn_debug_20070419.bz2 Please let me know if there is anything more that I can provide. Thanks, Daniel $ mtn diff -r d3347588d89228729eede7e314ae5b825aa698de ../plugins/win32/winprefs/winprefs.c mtn: fatal: std::logic_error: roster.cc:188: invariant 'fetching nonexistent entry from children' violated mtn: this is almost certainly a bug in monotone. mtn: please send this error message, the output of 'mtn --full-version', mtn: and a description of what you were doing to [EMAIL PROTECTED] mtn: wrote debugging log to c:/devel/pidgin-devel/pidgin/_MTN/debug mtn: if reporting a bug, please include this file $ mtn --full-version monotone 0.34 (base revision: 6ae6de16b31495a773ac3002505ad51f2e4a8616) Running on : Windows NT/2000/XP/2003 (5.1, build 2600, Service Pack 2) on ia32 (level 6, rev 3846) C++ compiler: GNU C++ version 3.4.5 (mingw special) C++ standard library: GNU libstdc++ version 20051201 Boost version : 1_33_1 Changes since base revision: format_version "1" new_manifest [34aa6f38c42c73d5542bafe2aa4514319a10a6bc] old_revision [6ae6de16b31495a773ac3002505ad51f2e4a8616] patch "Makefile.am" from [c7cdc7a6ff99623495792d2e28bebccc79483c67] to [9e12861012024b1d891f81f9534e654577bf6663] ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] encapsulation branch
On 19/04/2007, at 22:47, Markus Schiltknecht wrote: Hi, as you might have noticed, I've done some work in nvm.experiment.encapsulation. Based on Zack's idea, I've removed the app_state from lots of functions and objects. This has two reasons: - reducing the amount headers included - allow for read only database functionality (which is enforced by the compiler) Please have a look at rev 910e5113c9cec2c451fc4fe086c4793475a29606, where I have those four macros: AUTOMATE_WITH_EVERYTHING(.. AUTOMATE_WITH_DATABASE(.. AUTOMATE_WITH_WORKSPACE(.. AUTOMATE_WITH_NOTHING(.. Currently, I'm using some stub functions and I still heavily rely on having the app_state around in the database context. Anyway, for me, the point of the exercise is, finding out if it's worthwhile to achieve the above two goals. After lots of shuffling around of method arguments and such, I feel like walking on thin ice. I'd like to get some input. What do you think, is this the right way to do it? Shall we get rid of the app_state completely? What's the best way to handle commands with different requirements, i.e. ones need only a readable database, others want to write to the database and need a key_store, others need the workspace and a key_store, etc... I don't particularly like the #define's... Just FYI, I'm also messing with the way to define commands and subcommands, so I also have to look at how to define the automate ones. See the net.venge.monotone.help-rewrite branch (which currently builds but is severely broken). -- Julio M. Merino Vidal <[EMAIL PROTECTED]> ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] encapsulation branch
Hi, as you might have noticed, I've done some work in nvm.experiment.encapsulation. Based on Zack's idea, I've removed the app_state from lots of functions and objects. This has two reasons: - reducing the amount headers included - allow for read only database functionality (which is enforced by the compiler) Please have a look at rev 910e5113c9cec2c451fc4fe086c4793475a29606, where I have those four macros: AUTOMATE_WITH_EVERYTHING(.. AUTOMATE_WITH_DATABASE(.. AUTOMATE_WITH_WORKSPACE(.. AUTOMATE_WITH_NOTHING(.. Currently, I'm using some stub functions and I still heavily rely on having the app_state around in the database context. Anyway, for me, the point of the exercise is, finding out if it's worthwhile to achieve the above two goals. After lots of shuffling around of method arguments and such, I feel like walking on thin ice. I'd like to get some input. What do you think, is this the right way to do it? Shall we get rid of the app_state completely? What's the best way to handle commands with different requirements, i.e. ones need only a readable database, others want to write to the database and need a key_store, others need the workspace and a key_store, etc... I don't particularly like the #define's... Comments? Regards Markus ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: [ANN] Monotree 0.1 released
BTW: AFAIR Monotree was also the name of the Java front-end... ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Documentation and mtn-ignore
Hi everybody I was trying to ignore files by use of .mtn-ignore for the first time. Couldn't find sufficient information about .mtn-ignore/Lua patterns in the tutorial (i.e. section 3.8 would be a good place). The Lua was not the problem though, since I found documentation about Lua and patterns easyly. But I couldn't get the .mtn-ignore to work, until I found out, it has to placed in the workspaces root directory ... It was actualy the third place I tried, but since I didn't know Lua patterns bevor, I tried around for a while, testing the patterns in the wrong placed file with 'mtn ls ignored ./' bevor reading the Lua-Doku and finaly trying other directories for the .mtn-ignore file. It would be nice if that would have been made obvious (maybe together with some simple Lua-patterns). Currently there seams to be information about this in the Wiki eather. Thanks for all -- Sebastian Rose <[EMAIL PROTECTED]> ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] merge commands arguments
Hello all, I see some inconsistency in merge command parameters. 1. explicit_merge & merge They lack possibility to override message by '--message' and '--message-file' arguments 2. merge_into_dir Has all interesting arguments to customize revision info but: Why one can't merge from explicit revision but only from head of some branch ? Maybe merge_into_dir should have syntax changed from: merge_into_dir SOURCE-BRANCH DEST-BRANCH DIR to merge_into_dir SOURCE-REV DEST-BRANCH DIR so one can use any selector as SOURCE-REV to choose revision. It may be convenient to have those parameters. Don't know whether it's 'by design' or just anyone needed to make it consistent. I'm thinking about fixing those issues so I'm just asking for comments. -- Zbigniew -zbigg- Zagórski -- software developer -- geek -- happy daddy -- ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
