Re: [Monotone-devel] Questions pertaining Eclipse Integration
Timothy Brownawell wrote: On Sat, 2006-10-28 at 23:57 +0200, Ulf Ochsenfahrt wrote: Attached is a patch that changes mtn default behavior to add non-recursively and uses the -R option to reenable old behavior. This patch makes the add and drop commands more similar. I've committed changes that do this (started with your patch, but it Great! turns out there was additional work needed for some interesting cases Aha. Such as? having to do with the workspace root dir) and also give add a --no-respect-ignore switch. What does that do? -- Ulf smime.p7s Description: S/MIME Cryptographic Signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Questions pertaining Eclipse Integration
On Fri, 2006-11-03 at 11:26 +, Ulf Ochsenfahrt wrote: Timothy Brownawell wrote: On Sat, 2006-10-28 at 23:57 +0200, Ulf Ochsenfahrt wrote: Attached is a patch that changes mtn default behavior to add non-recursively and uses the -R option to reenable old behavior. This patch makes the add and drop commands more similar. I've committed changes that do this (started with your patch, but it Great! turns out there was additional work needed for some interesting cases Aha. Such as? Actually two things. One was that get_path_status() had to be fixed to work with the workspace root (and then this broke pivot_root, so that had to be fixed as well...). Another was that trying to add a nonexistent file would crash instead of giving a nice error (because addition_builder assumed that if it was told not to be recursive, it would be given only existing files). There were also several test cases that had to be adjusted for the new behavior. having to do with the workspace root dir) and also give add a --no-respect-ignore switch. What does that do? It tells monotone to not use the ignore_file() hook, so you can add ignorable files without using --nostd and losing all your other hooks. And it also has a slightly more clear name for that purpose. MasterYoda how do I add ignorable files to monotone? njs MasterYoda: the hack is --nostd, which prevents the default ignore hook from being used uep yeah. the problem with just adding a file if its named explicitly on the command line, even if it would otherwise be ignored, is that shell globs can expand to include ignored files uep after some thought, we decided it would be a bug to add something in that case - and we can't tell whether the files named came from a glob or were typed by the user directly -- Timothy Free (experimental) public monotone hosting: http://mtn-host.prjek.net ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Questions pertaining Eclipse Integration
On Sat, 2006-10-28 at 23:57 +0200, Ulf Ochsenfahrt wrote: Timothy Brownawell wrote: 'mtn drop -R' is recursive. (hey, we do have a --recursive option. Can we add a --non-recursive and kill --depth?) Attached is a patch that changes mtn default behavior to add non-recursively and uses the -R option to reenable old behavior. This patch makes the add and drop commands more similar. I've committed changes that do this (started with your patch, but it turns out there was additional work needed for some interesting cases having to do with the workspace root dir) and also give add a --no-respect-ignore switch. -- Timothy Free (experimental) public monotone hosting: http://mtn-host.prjek.net ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: recursivity (was Re: [Monotone-devel] Questions pertaining Eclipse Integration)
On Tue, Oct 31, 2006 at 08:03:20PM -0800, J Decker wrote: I doubt anyone wants commit . or diff . to be interpreted non-recursively (at least without some sort of --non-recursive flag). Is this a compelling argument for add/drop to behave the same way? Is there a flag to do this? I wanted to do those, and pluck . to just handle that particular directory. There are plugin directories under the main that I had changes in that I certainly did not want commited, the developers claim under there that if I touch it I own it. Try --depth -- not the best UI yet, but should be possible to do what you want. Back to the parent discussion -- is this something you would want to be the default, or just something you needed to do in one special case? -- Nathaniel -- Damn the Solar System. Bad light; planets too distant; pestered with comets; feeble contrivance; could make a better one myself. -- Lord Jeffrey ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: recursivity (was Re: [Monotone-devel] Questions pertaining Eclipse Integration)
I doubt anyone wants commit . or diff . to be interpreted non-recursively (at least without some sort of --non-recursive flag).Is this a compelling argument for add/drop to behave the same way?Is there a flag to do this? I wanted to do those, and pluck . to just handle that particular directory. There are plugin directories under the main that I had changes in that I certainly did not want commited, the developers claim under there that if I touch it I own it. -- Nathaniel--In mathematics, it's not enough to read the wordsyou have to hear the music___Monotone-devel mailing list Monotone-devel@nongnu.orghttp://lists.nongnu.org/mailman/listinfo/monotone-devel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Questions pertaining Eclipse Integration
In message [EMAIL PROTECTED] on Sat, 28 Oct 2006 19:27:18 -0500, Timothy Brownawell [EMAIL PROTECTED] said: tbrownaw I'm not sure we want to change the default, the tbrownaw recursiveness is kinda nice. Yes and no. Yes, I love it when it does include all files *when I want that to happen*. Also, it's quite confusing that it work differently from its opposite, drop. There are times, when I'm tired, where I get a bit frustrated because it doesn't work like it used to before I realise that I was thinking about the other command. Inconsistency can be a bitch at times. 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
Re: [Monotone-devel] Questions pertaining Eclipse Integration
On 10/29/06, Richard Levitte - VMS Whacker [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED] on Sat, 28 Oct 2006 19:27:18 -0500, Timothy Brownawell [EMAIL PROTECTED] said: tbrownaw I'm not sure we want to change the default, the tbrownaw recursiveness is kinda nice. Yes and no. Yes, I love it when it does include all files *when I want that to happen*. Also, it's quite confusing that it work differently from its opposite, drop. There are times, when I'm tired, where I get a bit frustrated because it doesn't work like it used to before I realise that I was thinking about the other command. Inconsistency can be a bitch at times. Agree with you. I would lobby for the default to not be recursive, but the fact is others scm's (like subversion) default to being recursive, so maybe is what users expect. On the other hand, I find it terribly annoying that after I do a mtn add * and then do a mtn drop * to make it forget about my mistake it bails out with mtn: misuse: path '_MTN' is in bookkeeping dir. That makes it untrivial to repair a mistake that is completely harmless (as no commit was done and no files are changed). I believe this is a side effect of renaming from the old dotted .mtn name, and would consider this a bug, because if people wanted this to happen, they would had codded this behaviour before. Regards, ~Nuno Lucas Cheers, Richard ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Questions pertaining Eclipse Integration
On 10/29/06, Nuno Lucas [EMAIL PROTECTED] wrote: I believe this is a side effect of renaming from the old dotted .mtn name, and would consider this a bug, because if people wanted this to happen, they would had codded this behaviour before. This behavior was most likely there before (haven't checked). But when * gets expanded, it does not pick dotted files (because they are hidden) so you didn't see the message because monotone never got .mtn as an argument to drop. -- Julio M. Merino Vidal [EMAIL PROTECTED] The Julipedia - http://julipedia.blogspot.com/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
recursivity (was Re: [Monotone-devel] Questions pertaining Eclipse Integration)
On Sun, Oct 29, 2006 at 09:55:41AM +0100, Richard Levitte - VMS Whacker wrote: In message [EMAIL PROTECTED] on Sat, 28 Oct 2006 19:27:18 -0500, Timothy Brownawell [EMAIL PROTECTED] said: tbrownaw I'm not sure we want to change the default, the tbrownaw recursiveness is kinda nice. Yes and no. Yes, I love it when it does include all files *when I want that to happen*. Also, it's quite confusing that it work differently from its opposite, drop. There are times, when I'm tired, where I get a bit frustrated because it doesn't work like it used to before I realise that I was thinking about the other command. Inconsistency can be a bitch at times. Consistency is really the issue at hand -- not only is there consistency between add and drop to think about, but also consistency between them and other restriction commands. I doubt anyone wants commit . or diff . to be interpreted non-recursively (at least without some sort of --non-recursive flag). Is this a compelling argument for add/drop to behave the same way? -- Nathaniel -- In mathematics, it's not enough to read the words you have to hear the music ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Questions pertaining Eclipse Integration
In message [EMAIL PROTECTED] on Sun, 29 Oct 2006 11:44:08 +, Nuno Lucas [EMAIL PROTECTED] said: ntlucas I believe this is a side effect of renaming from the old ntlucas dotted .mtn name, and would consider this a bug, because if ntlucas people wanted this to happen, they would had codded this ntlucas behaviour before. Uhmm, the admin directory was never named .mtn... 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
Re: [Monotone-devel] Questions pertaining Eclipse Integration
On Sun, Oct 29, 2006 at 11:44:08AM +, Nuno Lucas wrote: I believe this is a side effect of renaming from the old dotted .mtn name, and would consider this a bug, because if people wanted this to happen, they would had codded this behaviour before. Err... it was never called .mtn; the bookkeeping directory used to just be MT. -- Nathaniel -- The Universe may / Be as large as they say But it wouldn't be missed / If it didn't exist. -- Piet Hein ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Questions pertaining Eclipse Integration
On 10/30/06, Nathaniel Smith [EMAIL PROTECTED] wrote: On Sun, Oct 29, 2006 at 11:44:08AM +, Nuno Lucas wrote: I believe this is a side effect of renaming from the old dotted .mtn name, and would consider this a bug, because if people wanted this to happen, they would had codded this behaviour before. Err... it was never called .mtn; the bookkeeping directory used to just be MT. Now that you talk about it, don't know where I got this confusion. The brain (specially mine) is tricky sometimes... Anyway, just checked that it also fails with mtn add *, so don't understand how I got this confusion (probably did mtn add . and mtn drop *, because we can't do mtn drop . as it's not recursive by default). Shouldn't the default behavior simply ignore a mtn add/drop _MTN? Or simply say something like ignoring bookkeeping directory _MTN? Best regards, ~Nuno Lucas ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Questions pertaining Eclipse Integration
On Sat, 2006-10-28 at 18:23 +0200, Ulf Ochsenfahrt wrote: Hi all! I've got a few questions. Some of these may already have answers, others may not. I looked into the manual and checked the monotone built-in help, but found no easy answer to these. - How does monotone select a (default) key to sign? If you only have one key it uses that. There's also a get_branch_key hook that should at least work for commits. (it probably won't work for netsync, and I don't know about adding certs to revs that already exist) - How can I find out which? I don't know that you can at the moment. - Why is automate get_option not described in the manual? I don't know. It should be; this is a bug. - Why does automate get_option key return an empty string? If you give '--key=foo' it returns 'foo'. I'm assuming that all it does is say what options were given on the command line, but I haven't actually checked the code. - How can I add a directory non-recursively? ...why doesn't add take --depth? Anyway, aside from changing that, you can probably just add the directory and then drop all its children. - How can I suppress the automatic commit message dialog and get an error instead if no message was given on the command line? Probably by giving it an edit_comment hook that just returns false/nil (don't remember which). This could go in _MTN/monotonerc, or in some other file that you specify with --rcfile if you want your users to be able to run monotone operations on their workspace manually and get normal behavior. -- Timothy Free (experimental) public monotone hosting: http://mtn-host.prjek.net ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Questions pertaining Eclipse Integration
Richard Levitte - VMS Whacker wrote: ulf - How can I suppress the automatic commit message dialog and get ulf an error instead if no message was given on the command line? You hack your own edit_comment function in _MTN/monotonerc (works only with that workspace) or ~/.monotone/monotonerc (works for everything you do). ...or (as is probably most useful for the plugin), write out some temporary rc file and use --rcfile. That said, to avoid this kind of playing with temporary files, it might be useful if monotone started taking a --rccode=...LUA code... parameter? -- Jon ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Questions pertaining Eclipse Integration
In message [EMAIL PROTECTED] on Sat, 28 Oct 2006 20:48:51 +0200, Jon Bright [EMAIL PROTECTED] said: jon ...or (as is probably most useful for the plugin), write out some jon temporary rc file and use --rcfile. That said, to avoid this jon kind of playing with temporary files, it might be useful if jon monotone started taking a --rccode=...LUA code... parameter? Hey bud, check this out (I discovered while looking around the code to see how hard it would be to implement --rccode :-)): : ; echo 'io.stderr:write FOO!\n' | mtn heads --rcfile=- FOO! mtn: grenen 'net.venge.monotone' har för tillfället ett löv: 970b5cf42c0202a0b1a236ed7034f47c117c2f79 [EMAIL PROTECTED] [EMAIL PROTECTED] 2006-10-27T11:48:03 2006-10-27T14:20:29 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
Re: [Monotone-devel] Questions pertaining Eclipse Integration
Richard Levitte - VMS Whacker wrote: Hey bud, check this out (I discovered while looking around the code to see how hard it would be to implement --rccode :-)): : ; echo 'io.stderr:write FOO!\n' | mtn heads --rcfile=- FOO! mtn: grenen 'net.venge.monotone' har för tillfället ett löv: 970b5cf42c0202a0b1a236ed7034f47c117c2f79 [EMAIL PROTECTED] [EMAIL PROTECTED] 2006-10-27T11:48:03 2006-10-27T14:20:29 Nice to know, and cool that it works... but not that handy with automate stdio, which is what most integration stuff will be using :-) -- Jon ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Questions pertaining Eclipse Integration
In message [EMAIL PROTECTED] on Sat, 28 Oct 2006 21:17:11 +0200, Jon Bright [EMAIL PROTECTED] said: jon Richard Levitte - VMS Whacker wrote: jon jon Hey bud, check this out (I discovered while looking around the code to jon see how hard it would be to implement --rccode :-)): jon jon : ; echo 'io.stderr:write FOO!\n' | mtn heads --rcfile=- jon FOO! jon mtn: grenen 'net.venge.monotone' har för tillfället ett löv: jon 970b5cf42c0202a0b1a236ed7034f47c117c2f79 [EMAIL PROTECTED] [EMAIL PROTECTED] 2006-10-27T11:48:03 2006-10-27T14:20:29 jon jon Nice to know, and cool that it works... but not that handy with jon automate stdio, which is what most integration stuff will be jon using :-) Then you're using something other than --rccode, aren't you? Because the above basically fulfills the needs of --rccode, as far as I can see. 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
Re: [Monotone-devel] Questions pertaining Eclipse Integration
Hi, I'll try pasting together the answers from Richard and Timothy. - How does monotone select a (default) key to sign? Richard: If you only have one private key, monotone will choose it (I think, I haven't tested that for a while). If _MTN/options has a key identity in it, monotone will choose that. Otherwise, you specify a key identity once, and its identity will be saved in _MTN/options. So basically, I first have to check mtn automate keys, and check if more then one private key is returned. Additionally, I have to check mtn automate get_option key, to see if a key was set for the particular workspace. That gives 6 possibilities: 1. no private key, no key set - error, can't commit 2. no private key, key set - error, can't commit 3. one private key, no key set - private key is default 4. one private key, key set - if both keys are the same, that one is default, if set key doesn't exist and isn't overriden, I can't commit 5. mult private key, no key set - no default key, have to choose for commit with --key= 6. mult private key, key set - set key is default, if exists, can be overriden with --key=, if set key doesn't exist and isn't overriden, I can't commit - Why is automate get_option not described in the manual? It would be nice if someone wrote a description. - How can I add a directory non-recursively? Richard: I'm not sure you can. If you want to add specific files in a directory, just add them, the directory itself will be added automagically if needed. Timothy: ...why doesn't add take --depth? Anyway, aside from changing that, you can probably just add the directory and then drop all its children. It would be nice to have a --non-recursive/--no-depth option, if the current is to stay the default. (Or conversely, add a --depth option and change the default to not add files recursively.) Adding the directory and then dropping the children isn't really an option. It invites quite a number of problems. What if a child is deleted in the meantime? What if the subtree is huge? Also, you'd have to recursively go through all subdirectories and first remove all their children. (I just checked, mtn drop returns an error message for a non-empty directory.) - How can I suppress the automatic commit message dialog and get an error instead if no message was given on the command line? --rcfile=- is a useable option, but when used with automate stdio, you'd have to know all information with regard to the rcfile before the mtn subprocess is started, or you have to start a new mtn subprocess, which severely limits its usability for frontend integration (e.g. Eclipse). It would be nice to have a global --non-interactive option, that makes mtn always return an error instead of asking on the console/starting an editor process. Alternatively, it might implicitly set this option, if the stdin/stdout isn't a console. Cheers, -- Ulf smime.p7s Description: S/MIME Cryptographic Signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Questions pertaining Eclipse Integration
Richard Levitte - VMS Whacker wrote: Then you're using something other than --rccode, aren't you? Because the above basically fulfills the needs of --rccode, as far as I can see. No. Using stdin to provide the script would be ideal. But if you're using automate stdio, stdin is already taken: you're using it to send commands to monotone. A solution which takes everything up to the first occurrence of some marker as being script before handing off to automate stdio might work, but at that point, --rccode may well be cleaner/more elegant. -- Jon ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Questions pertaining Eclipse Integration
On Sat, 2006-10-28 at 21:59 +0200, Ulf Ochsenfahrt wrote: - How can I add a directory non-recursively? Richard: I'm not sure you can. If you want to add specific files in a directory, just add them, the directory itself will be added automagically if needed. Timothy: ...why doesn't add take --depth? Anyway, aside from changing that, you can probably just add the directory and then drop all its children. It would be nice to have a --non-recursive/--no-depth option, if the current is to stay the default. (Or conversely, add a --depth option and change the default to not add files recursively.) I was thinking probably keep the same default, but add --depth so you can do --depth=0 to be non-recursive. (Why do we have --depth instead of a recursive/non-recursive flag? Does anyone actually use the extra flexibility?) Adding the directory and then dropping the children isn't really an option. It invites quite a number of problems. What if a child is deleted in the meantime? What if the subtree is huge? Yeah, these would make it annoying. But at present I think they're all that's available. Also, you'd have to recursively go through all subdirectories and first remove all their children. (I just checked, mtn drop returns an error message for a non-empty directory.) 'mtn drop -R' is recursive. (hey, we do have a --recursive option. Can we add a --non-recursive and kill --depth?) - How can I suppress the automatic commit message dialog and get an error instead if no message was given on the command line? --rcfile=- is a useable option, but when used with automate stdio, you'd have to know all information with regard to the rcfile before the mtn subprocess is started, or you have to start a new mtn subprocess, which severely limits its usability for frontend integration (e.g. Eclipse). It would be nice to have a global --non-interactive option, that makes mtn always return an error instead of asking on the console/starting an editor process. Alternatively, it might implicitly set this option, if the stdin/stdout isn't a console. I'm not sure how well this would work, since most interactive stuff is done by hooks (IIRC the only exception is prompting for passwords). And user-defined hooks might not choose to respect this option. -- Timothy Free (experimental) public monotone hosting: http://mtn-host.prjek.net ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Questions pertaining Eclipse Integration
On Sat, Oct 28, 2006 at 10:01:29PM +0200, Jon Bright wrote: Richard Levitte - VMS Whacker wrote: Then you're using something other than --rccode, aren't you? Because the above basically fulfills the needs of --rccode, as far as I can see. No. Using stdin to provide the script would be ideal. But if you're using automate stdio, stdin is already taken: you're using it to send commands to monotone. A solution which takes everything up to the first occurrence of some marker as being script before handing off to automate stdio might work, but at that point, --rccode may well be cleaner/more elegant. Random, possibly terrible idea: automate eval, which takes some lua code and evaluates it in the hook environment. -- Nathaniel -- The problem...is that sets have a very limited range of activities -- they can't carry pianos, for example, nor drink beer. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Questions pertaining Eclipse Integration
Timothy Brownawell wrote:
'mtn drop -R' is recursive. (hey, we do have a --recursive option. Can
we add a --non-recursive and kill --depth?)
Attached is a patch that changes mtn default behavior to add
non-recursively and uses the -R option to reenable old behavior. This
patch makes the add and drop commands more similar.
--depth is defined on commit, any other commands?
It would seem that it made sense to add --depth to commit at some point
or for a certain use-case.
Cheers,
-- Ulf
#
# old_revision [970b5cf42c0202a0b1a236ed7034f47c117c2f79]
#
# patch cmd_ws_commit.cc
# from [d91beffea3f99a325b152c0a7160ba966f1592f9]
#to [5a78b364b4281679e14e1282934c1ea2ce0b30e7]
#
--- cmd_ws_commit.ccd91beffea3f99a325b152c0a7160ba966f1592f9
+++ cmd_ws_commit.cc5a78b364b4281679e14e1282934c1ea2ce0b30e7
@@ -250,10 +250,11 @@ CMD(add, N_(workspace), N_([PATH]...
CMD(add, N_(workspace), N_([PATH]...),
-N_(add files to workspace), option::unknown)
+N_(add files to workspace), option::unknown % option::recursive)
{
if (!app.unknown (args.size() 1))
throw usage(name);
+ N(!app.unknown || !app.recursive, F(cannot set unknown and recursive at the same time));
app.require_workspace();
@@ -279,7 +280,7 @@ CMD(add, N_(workspace), N_([PATH]...
paths.insert(sp);
}
- bool add_recursive = !app.unknown;
+ bool add_recursive = app.recursive;
app.work.perform_additions(paths, add_recursive);
}
smime.p7s
Description: S/MIME Cryptographic Signature
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Questions pertaining Eclipse Integration
Nathaniel Smith wrote: That gives 6 possibilities: 1. no private key, no key set - error, can't commit 2. no private key, key set - error, can't commit 3. one private key, no key set - private key is default 4. one private key, key set - if both keys are the same, that one is default, if set key doesn't exist and isn't overriden, I can't commit 5. mult private key, no key set - no default key, have to choose for commit with --key= 6. mult private key, key set - set key is default, if exists, can be overriden with --key=, if set key doesn't exist and isn't overriden, I can't commit It would certainly be possible to add some way to ask monotone hey, if you were going to use a key, what key would you use? It basically hasn't been added yet because no-one needed it, mostly you can just run an operation and let monotone worry about what key it uses... What's your use case? Eclipse Plugin. It needs to know the key that would be used so it can show it to the user and allow the setting to be changed if necessary. It's not a high-priority issue, it just came up in my coding today. AFAICR there are only three places that monotone prompts for input: -- passphrases (if get_passphrase is not set; if it is set, then it can prompt or whatever it likes instead) -- commit comment editor (actually run by edit_comment hook) -- merge tools (actually run by merge3 hook) So basically you can implement --non-interactive using only hooks, if you want... I'm not sure what you want here, though, since first you complain about hooks being global and then you ask for a global switch instead :-). There are several issues here. Most importantly, when run in the background, mtn may never ever ask anything. That would just hang the entire Eclipse IDE or whatever other frontend (happened to me today), and you have to kill it manually. Again, it'd be nice to know more about your use cases -- the _easiest_ way to prevent the editor window from popping up is to just pass --message or --message-file on the command line, and your plugin has complete control of that :-). This is not just with respect to the editor window, it's got to do with everything (tm). Adding a global flag would make it easier to develop tools that use mtn in the background. The passphrase dialog on commit is my biggest problem right now. If the passphrase is set in the default monotonerc, then I'd rather just use that. If it's not set, I have to ask the user. Jon's original code would always ask the user, my current code never asks. Both approaches are clearly wrong. This is not solvable with hooks. If I override the passphrase hook, I can never use the passphrase from monotonerc. If I don't, I get stuck if the user doesn't provide it in monotonerc. More generally, for correctness, I'd rather have monotone fail instead of ask the user in all cases, when run in the background. Now and with whatever extensions at whatever point in the future. That's why I'm asking for a global flag. Alternatively, one could make the automate interface more powerful (needs at least add, drop, rename, and commit commands) and interpret that as --non-interactive. For commit (and thus to solve the passphrase issue), I think the best solution would be to add an automate commit command that takes a passphrase parameter and a key parameter and a message parameter (and maybe a couple more) and that fails if the passphrase doesn't work, or no message is specified, or no key could be selected for signing. Finally, I need to figure out which key mtn is going to use so I can give the user the appropriate information in the passphrase dialog. Cheers, -- Ulf smime.p7s Description: S/MIME Cryptographic Signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Questions pertaining Eclipse Integration
On Sat, 2006-10-28 at 23:57 +0200, Ulf Ochsenfahrt wrote: Timothy Brownawell wrote: 'mtn drop -R' is recursive. (hey, we do have a --recursive option. Can we add a --non-recursive and kill --depth?) Attached is a patch that changes mtn default behavior to add non-recursively and uses the -R option to reenable old behavior. This patch makes the add and drop commands more similar. --depth is defined on commit, any other commands? It would seem that it made sense to add --depth to commit at some point or for a certain use-case. Originally, we didn't have -R and just used --depth. But that doesn't make sense for drop, so I added -R. I'm not sure there *is* a reason it makes sense to use --depth instead of -R ; AFAIK the only reason we use --depth anywhere is that we didn't have -R yet. -- Timothy Free (experimental) public monotone hosting: http://mtn-host.prjek.net ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Questions pertaining Eclipse Integration
On Sun, 2006-10-29 at 00:37 +0200, Ulf Ochsenfahrt wrote: [...] The passphrase dialog on commit is my biggest problem right now. If the passphrase is set in the default monotonerc, then I'd rather just use that. If it's not set, I have to ask the user. Jon's original code would always ask the user, my current code never asks. Both approaches are clearly wrong. This is not solvable with hooks. If I override the passphrase hook, I can never use the passphrase from monotonerc. If I don't, I get stuck if the user doesn't provide it in monotonerc. old_get_passphrase = get_passphrase function get_passphrase(keyname) -- do whatever, maybe including calling old_get_passphrase end Of course, for your hook to be able to announce that the passphrase wasn't provided to old_get_passphrase and have your plugin supply it you'd probably need another channel of communication between monotone and your plugin. More generally, for correctness, I'd rather have monotone fail instead of ask the user in all cases, when run in the background. Now and with whatever extensions at whatever point in the future. That's why I'm asking for a global flag. Maybe we can have a can you use this key? thing under automate that will say whether you need to supply the password? Alternatively, one could make the automate interface more powerful (needs at least add, drop, rename, and commit commands) and interpret that as --non-interactive. This would probably be good, but can probably only work for the password prompt. -- Timothy Free (experimental) public monotone hosting: http://mtn-host.prjek.net ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Questions pertaining Eclipse Integration
On Sat, 2006-10-28 at 23:57 +0200, Ulf Ochsenfahrt wrote: Timothy Brownawell wrote: 'mtn drop -R' is recursive. (hey, we do have a --recursive option. Can we add a --non-recursive and kill --depth?) Attached is a patch that changes mtn default behavior to add non-recursively and uses the -R option to reenable old behavior. This patch makes the add and drop commands more similar. I'm not sure we want to change the default, the recursiveness is kinda nice. I suppose we could apply this after the next release (should be any day now, I think), which would let us try it out for a while and see if we want to put recursive back as the default behavior. -- Timothy Free (experimental) public monotone hosting: http://mtn-host.prjek.net ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Questions pertaining Eclipse Integration
Timothy == Timothy Brownawell Timothy writes: Timothy I'm not sure we want to change the default, the Timothy recursiveness is kinda nice. For the add operation, I very much dislike it. Especially when it automatically adds files that I don't want it to add. I am not sure if monotone will blindly add *.bak files (like another system I have used does), but in any case I think it is much easier to recover from accidently not using recursive when you wanted it to accidently using recursive when you only want to add one directory. As such, I think non-recursive should be the default. -- Brian May [EMAIL PROTECTED] ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
