Re: [Monotone-devel] [PATCH] mtn automate set_option
"Ben Walton" <[EMAIL PROTECTED]> wrote: > Yah, I'm new, but I may be missing the point a little still. When > thinking in the context of wrapping mtn in a gui (the whole point of > the automate commands), isn't it desirable to have a programmatic > interface to things like the options file? I would have to agree on this one. Isn't the goal to separate the UI completely, being able to run monotone completely from within such an interface? If so, being able to get and set options seems pretty fundamental. -- Chad Walstrom <[EMAIL PROTECTED]> http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [PATCH] mtn automate set_option
On Sat, Dec 23, 2006 at 01:22:21AM +0100, Thomas Keller wrote: > Don't get me wrong, but how is he supposed to know that? Well, because I just told him :-). Maybe he will find the information useful, maybe not. I guess there are a few possible outcomes. Maybe neither Ben nor anyone else actually knows what use such a feature would be, in which case we learn that it's not worth spending time on before any more resources are sunk into it, and record that fact in the mailing list archives. Or perhaps we will learn that it is useful, but in such rare and tenuous cases that we could get 100 times the benefit by spending the same resources working on some other feature, and we will all get a nice lesson on why the concept of "opportunity cost" is so useful. Or perhaps we will learn that it is actually a great idea, and will be convinced to spend more time on it (and the reasons for _that_ will be recorded in the mailing list archive too). Or perhaps we will learn that it isn't such a great idea as is, _but_ discover some other similar feature that none of us even thought of before, that is really useful. ...Or maybe it will simply provoke a general discussion of resource allocation in a volunteer project, which is always a tricky topic :-). (Also note that I didn't say "this patch sucks and you should print it out so you can feed it to your dog"; I was just explaining why I was nervous about investing my own time in it, and hoping to create useful discussion. If other people want to get it landed on mainline, then I'm not likely to invest my time in stopping that either, unless it were missing tests or had egregrious coding issues or something.) > Maybe we should > start and explicitely name / comment certain things as "temporary, will > be replaced", so no manpower goes into that? Maybe -- there was some discussion in the past of having a class of "experimental" automate commands, that are second-class citizens in the sense that they do not have compabitility guarantees, and should eventually either be promoted tor be "real" automate commands, or else removed. Clients would have to take some affirmative action to request access to such commands (like using 'automate_experimental' in place of 'automate', or something). No-one has written any infrastructure for this, though it would probably not be too hard. HTH, -- Nathaniel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [PATCH] mtn automate set_option
Yah, I'm new, but I may be missing the point a little still. When thinking in the context of wrapping mtn in a gui (the whole point of the automate commands), isn't it desirable to have a programmatic interface to things like the options file? It's not a mainstream, everyday feature by any means, but if it's not in mtn, it would end up being duplicated in each gui that wraps mtn. Hiding inside the automate family of commands allows the mtn backend implementation to change without necessarily affecting the clients that use it. If all of a sudden _MTN/options was to be called _MTN/options_v2, only mtn would need to be modified, not the gui wrappers, for example. It could also hide renamed options, but accepting old_name || new_name as well, providing a migration path for clients to update their code. Apologies if I'm off base with my line of thinking. Also, I'm just looking for more things to hack on to get into the code more. If my patches aren't useful, that's ok. I've learned more about mtn by writing them, so they're still useful to me, if only as an exercise. Thanks -Ben On 12/22/06, Thomas Keller <[EMAIL PROTECTED]> wrote: Nathaniel J. Smith schrieb: > On Thu, Dec 21, 2006 at 03:04:22PM -0500, Ben Walton wrote: >> I cooked this up today as a corollary to get_option. I hope it's useful. > > So, umm... before investing time in reviewing the patch, rewriting > internal interfaces, answering future support questions, etc... _do_ > you have any ideas where it would be useful? Because I'm not really > sure myself (_MTN/options is really an implementation detail kind of > thing, and now that I think about it get_option is really unlikely to > survive into mtn 1.0), and it seems silly to spend that time unless > it's plausible that there will be commensurate rewards? Don't get me wrong, but how is he supposed to know that? Maybe we should start and explicitely name / comment certain things as "temporary, will be replaced", so no manpower goes into that? In the end get_option as well as set_option is just some interface to something which has been introduced into monotone for some time (workspace options), probably long before I knew monotone, but didn't get proper UI support until now. IMHO there are use cases when get/set_option is useful, now the question is if these use cases should get support or if we should throw them over because they're just of temporary nature? Thomas. -- ICQ: 85945241 | SIP: 1-747-027-0392 | http://www.thomaskeller.biz > Guitone, a frontend for monotone: http://guitone.berlios.de > Music lyrics and more: http://musicmademe.com -- --- Ben Walton <[EMAIL PROTECTED]> Unanswered questions are far less dangerous than unquestioned answers. - The Roadside Pulpit --- ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [PATCH] mtn publish
On 12/22/06, Nathaniel J. Smith <[EMAIL PROTECTED]> wrote: On Thu, Dec 21, 2006 at 10:25:35AM -0500, Ben Walton wrote: > I don't want the clients seeing _MTN/*. I accept your assertion, but am curious about your reasons :-). It seems like _MTN/* takes completely negligible space, and provides potentially valuable information? But...it's only valuable information if the clients needed to contribute info back to a db. In the uses I'm putting it to, it's completely extraneous info except in my working copy. I agree that the space is negligible, and it certainly wouldn't hurt to have the clients see it either... My goal is to have cfengine on the master server periodically do an export from the db, which will be picked up by the clients (of which it counts itself a member too). This would allow me to develop the scripts completely outside of the primary repository that clients update from. The cfengine update script could just rm the _MTN itself too, if found, or even do an update && rm --unknown as well. Many ways to skin a cat. > I realize that this could be done with a script also, so if you feel > that this is a silly feature, my feelings will not be hurt if the > patch isn't accepted. I don't really have any opinion either way -- I've never felt that "rm -rf _MTN" was particularly onerous, but hey, if abstraction gives people fuzzies and keeps them warm at night... Agreed, this is just a warm fuzzy feature. General comments on the design follow: > The semantics are almost identical to checkout, except that it will > not checkout to the cwd. It also introduces a --force option to be > used in the event where the publishing destination directory already > exists. If the destination exists and is a file, mtn will abort...I > felt that this was more dangerous than overriding a directory. An > existing directory is backed up and left in place. I have never seen a good reason to name an option "--force" -- the name conveys almost nothing about what it actually does, and so people inevitably end up wanting to pile other a grab bag of behaviors under the same switch, and users inevitably end up trying it whenever they see an error, just in case _this_ happens to the error that --force turns off... And, of course, there's the always enjoyable question of how to name backups, and what to do if the name is in use. Do you actually have a need for the ability to clobber an existing directory with this command? It seems like it would be easier to just tell users to do their own "rm -rf $FOO", or "[ -e $FOO ] && mv b$FOO $FOO.bak" or whatever particular policy they like. Ok, point taken. --force is likely a bad choice for the reasons you've listed above. Backup naming is always a challenge, no doubt. Using the pid should avoid collissions for a while at least (unless you hang out with Murphy), but is far from reliable in the long run...this could be beefed up with pid.revision (where revision increments until it hits max_int or something), but that's getting carried away. I'd be more inclined to rename --force to --update-existing or similar, and completely remove the old directory after a successful export. ...Like I said, this is about 2 lines of shell script, so if it's not a desirable feature, we can just drop it altogether. -- Nathaniel -- --- Ben Walton <[EMAIL PROTECTED]> Unanswered questions are far less dangerous than unquestioned answers. - The Roadside Pulpit --- ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] question regarding stdio and streams
Nathaniel J. Smith schrieb: I'm afraid this is rather hypothetical for me to have anything useful to say. If you just want to be able to take arbitrary text from monotone and dump it at the user, I suppose capturing stderr is not too hard either... Yes, of course, but then I think stderr in stdio should be reserved to errors coming from automate stdio itself, not from commands run within stdio... like "your appartment exploded, can't run stdio" sort of errors... =) > but probably you do want more than that, i.e., structured status information, which would require quite a different solution... but this is all for the use of commands that don't even exist, so who knows what they will actually need... dunno. I quickly implemented push/pull/sync for automate in some branch, and automate genkey already spits out messages on clog when creating a new key, so this problem exists already. One possible solution for me would be that the P() macro would print out either to clog or cout (in stdio format) dependent if a command is called from within stdio or not. But I guess this is too complicable or not even doable without even more interfering magic (see how I tried to implement tickers in stdio...) Thomas. -- ICQ: 85945241 | SIP: 1-747-027-0392 | http://www.thomaskeller.biz > Guitone, a frontend for monotone: http://guitone.berlios.de > Music lyrics and more: http://musicmademe.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] question regarding stdio and streams
On Fri, Dec 22, 2006 at 08:47:32AM +0100, Thomas Keller wrote: > Nathaniel J. Smith schrieb: > > If you want to include the information into automate stdio's stdout > > stream, you need to multiplex it in somehow, and I don't have any > > particular opinion on what the best way would be to write such code. > > I'm sort of surprised you even want it :-). > > The reason why it could be useful is because it contains status > information of what is currently going on, i.e. for mtn automate > push/pull/sync, which would be (if not merged into stdout) just hidden > for a GUI. Those messages tell the user again to which server he > connects, if a key (or anonymous access) is used and finally if the > process itself was a success. Now if this is missing, this is not such a > bad thing, if the process wouldn't spend sometimes more time on these > steps (i.e. connecting to a server) while the user doesn't get any > feedback on the action. The command line GUI tell me what it does, over > automate I can't see what happens. I'm afraid this is rather hypothetical for me to have anything useful to say. If you just want to be able to take arbitrary text from monotone and dump it at the user, I suppose capturing stderr is not too hard either... but probably you do want more than that, i.e., structured status information, which would require quite a different solution... but this is all for the use of commands that don't even exist, so who knows what they will actually need... dunno. > Btw... a sidenode, could it be that clog is by default redirected to > cerr anyways? At least here on OSX if I do 2>/dev/null, the log messages > disappear, while they are still available if I redirect stdout to > /dev/null. Before looking at monotone's sources I didn't even know of a > clog output stream, but thought cout and cerr where the only (used) ones... Yes, clog and cerr are identical, except that clog is an ordinary ostream while cerr is magic. (In particular, I think cerr is unbuffered or something like that.) Both point to fd number 2, also known as "stderr". -- Nathaniel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [PATCH] mtn automate set_option
Nathaniel J. Smith schrieb: On Thu, Dec 21, 2006 at 03:04:22PM -0500, Ben Walton wrote: I cooked this up today as a corollary to get_option. I hope it's useful. So, umm... before investing time in reviewing the patch, rewriting internal interfaces, answering future support questions, etc... _do_ you have any ideas where it would be useful? Because I'm not really sure myself (_MTN/options is really an implementation detail kind of thing, and now that I think about it get_option is really unlikely to survive into mtn 1.0), and it seems silly to spend that time unless it's plausible that there will be commensurate rewards? Don't get me wrong, but how is he supposed to know that? Maybe we should start and explicitely name / comment certain things as "temporary, will be replaced", so no manpower goes into that? In the end get_option as well as set_option is just some interface to something which has been introduced into monotone for some time (workspace options), probably long before I knew monotone, but didn't get proper UI support until now. IMHO there are use cases when get/set_option is useful, now the question is if these use cases should get support or if we should throw them over because they're just of temporary nature? Thomas. -- ICQ: 85945241 | SIP: 1-747-027-0392 | http://www.thomaskeller.biz > Guitone, a frontend for monotone: http://guitone.berlios.de > Music lyrics and more: http://musicmademe.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [PATCH] mtn automate set_option
On Thu, Dec 21, 2006 at 03:04:22PM -0500, Ben Walton wrote: > I cooked this up today as a corollary to get_option. I hope it's useful. So, umm... before investing time in reviewing the patch, rewriting internal interfaces, answering future support questions, etc... _do_ you have any ideas where it would be useful? Because I'm not really sure myself (_MTN/options is really an implementation detail kind of thing, and now that I think about it get_option is really unlikely to survive into mtn 1.0), and it seems silly to spend that time unless it's plausible that there will be commensurate rewards? -- Nathaniel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [PATCH] mtn publish
On Thu, Dec 21, 2006 at 10:25:35AM -0500, Ben Walton wrote: > I don't want the clients seeing _MTN/*. I accept your assertion, but am curious about your reasons :-). It seems like _MTN/* takes completely negligible space, and provides potentially valuable information? > I realize that this could be done with a script also, so if you feel > that this is a silly feature, my feelings will not be hurt if the > patch isn't accepted. I don't really have any opinion either way -- I've never felt that "rm -rf _MTN" was particularly onerous, but hey, if abstraction gives people fuzzies and keeps them warm at night... General comments on the design follow: > The semantics are almost identical to checkout, except that it will > not checkout to the cwd. It also introduces a --force option to be > used in the event where the publishing destination directory already > exists. If the destination exists and is a file, mtn will abort...I > felt that this was more dangerous than overriding a directory. An > existing directory is backed up and left in place. I have never seen a good reason to name an option "--force" -- the name conveys almost nothing about what it actually does, and so people inevitably end up wanting to pile other a grab bag of behaviors under the same switch, and users inevitably end up trying it whenever they see an error, just in case _this_ happens to the error that --force turns off... And, of course, there's the always enjoyable question of how to name backups, and what to do if the name is in use. Do you actually have a need for the ability to clobber an existing directory with this command? It seems like it would be easier to just tell users to do their own "rm -rf $FOO", or "[ -e $FOO ] && mv b$FOO $FOO.bak" or whatever particular policy they like. -- Nathaniel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
