[Monotone-devel] git fast-export
I've spent a bit of holiday hacking time working on a git_export command for monotone, more as an experiment than anything else. I've committed the result to net.venge.monotone.fast-export for people to have a look at. There's probably not much preventing this from landing on mainline, other than some documentation and possibly tests. Although I'm not really sure how we would want to go about testing it beyond what I've already done. The fun part about a command like this is that I expect most users of it would have some expectation of being their own testers in terms of verifying their conversions and such. This successfully (I think) converts the entire monotone database with 276 branches (more or less what you get when you pull '*' from monotone.ca) to a git repository.Here's some details on the conversion: exported monotone database - 174MB in size - 276 branches - 127 tags (with one duplicate name monotone-viz-1.0.1-1 - export time 83m42.134s (on a 2.0GHz pentium-m laptop) - export file size 2.9GB - 15245 revisions exported imported git repository - 719MB in size (before being repacked) - import time 23m15.463s - repack -adf time 3m14.385s - packed repository size 60MB - 277 branches (the extra one is "master") - 126 tags (missing the duplicate above) Three exported branch names "net.prjek:tester", "net.prjet:tester/drop-for-propagate" and "prjek.net:tester" where changed (with sed) during the import process because git does not allow colon's (and various other characters) in branch/ref names. I simply changed ":" and "/" in these names to "." although the "/" should have worked it did cause an error of some sort. The conversion was verified by checking out each of the 276 branches and 126 tags from both git and mtn and comparing the resulting workspaces. The script I used to do this verification was a bit dumb and failed to checkout a few revisions so these weren't compared. Using only the branch name failed in some cases because there were multiple heads and using only a tag name failed in some cases because the tagged revisions had no branch certs. All of the branches and tags that did checkout were identical according to diff -qr so I'm reasonably confident that the new exporter basically works. I suspect that the various other git fast-import conversion scripts that exist for monotone are probably slower and less robust than this implementation (unless they work similarly from rosters) which uses the monotone internals to do the work. I spent a bit of time initially trying to export revisions using the revision data structures but this didn't work very well. Git only deals with files and trying to order a mix of renames of directories and files from monotone correctly from revisions was difficult. Ultimately I didn't use the revision data structures at all but built up a similar files-only based revision representation by comparing rosters. Much like what is done for make_cset, but ignoring directories and producing only file deletions, renames and additions. This works much better, correctly handles pivot_root and a few other odd things that working with revisions proved difficult. This exporter does not (yet) handle all rename ordering issues that are possible. For example followed by will probably fail on import unless it is executed as followed by . Similarly followed by which is indeed possible, will probably fail on import and requires the introduction of a third temporary file. These problems can be fixed in the exporter and can also be fixed in the exported data by re-ordering renames as required. WARNING: Please don't bet your life on this implementation! If you do use it to convert a repository you must do careful verification of the converted results. WORKSFORME is the only assurance I can make. This feels a bit like throwing in the proverbial towel and I hope this doesn't elicit any ill-will from the current monotone crowd. I'm not really planning on converting my personal stuff from monotone any time soon but knowing it can be done without losing information is nice. I'm still happy to contribute to monotone but with 2 small kids my free/hacking time is pretty limited. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] "throw usage(); " or "N(); " for argument checking?
Zack Weinberg schrieb: A command that does "throw usage()" gives the same result as calling "mtn help ", printing full usage info to stderr, where N() results in "mtn: misuse: " on stderr and will put a note in any debug log. >>> As long as the is maintained in case of "throw usage()", I'm >>> fine. I dislike tools which just throw the complete usage page at me and >>> let me figure myself. Some hint on what's wrong certainly helps. And >>> that hint should survive, IMO. >> So I guess we should standardize on "throw usage()", but give usage a >> what() and make the constructor take a message. > > I'm dubious about printing the full usage message on any command line > mistake. Those are often long enough that they make the actual > diagnostic scroll off the top of the terminal or at least be visually > lost in a sea of chatter. > > What would be really good is if we could give customized usage advice > based on the error, e.g. currently we have > > $ mtn ls > mtn: misuse: no subcommand specified for 'ls' > > but 'mtn help ls' prints a 55-line message the relevant part of which > is in the *middle.* It would be great if we could extract just the > "subcommands of 'mtn ls'" part of that message and print it after the > above diagnostic. And while we're at it I'd like to add some --show-global-options option to `mtn help' to prevent the additional 22 line output of global options which should be commonly known to users. Or have some `mtn help options' command which does exactly that. Thomas -- GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz Please note that according to the EU law on data retention, information on every electronic information exchange might be retained for a period of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: nvm.dates review
I've now pushed some revs to nvm.dates in which I made many of the changes you said you would rather not do. I feel I ought to explain why I'm insisting on those changes. I have some further changes in mind for date handling, but I'm not going to get to them for a couple days. If you would like to merge nvm.dates and nvm.dates.statistics into mainline now, please go ahead. On Mon, Oct 27, 2008 at 8:42 AM, Markus Wanner wrote: > Zack Weinberg wrote: >> + // 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. > > I felt the factory function to be overly verbose. Guess that's a matter > of taste. I didn't change that for now. I made the ::from_string() factory into a constructor but left ::now() and the other constructors alone. That's enough consistency for me. >> + void gmtime(struct tm & tm) const; >> + void mktime(struct tm const & tm); > > To keep it clear that these methods are about equivalent to the system > functions, I've now prefixed them with "our_". Feel free to rename to > whatever else you find more appropriate, but please keep it clear that > these provide similar functionality. I changed "our_mktime" to "our_timegm". The system function mktime() operates in the local timezone so it is clearer not to use that name at all for a function that operates in GMT. Some (unfortunately not all) systems have timegm() that operates in GMT. >> Here and elsewhere - since you took out the buffer that would be too >> small in CE 1, why are you still restricting the year to <= ? > > Because that's been the limit before in date_t::now() and I thought > is far enough in the future for our use. Practically speaking, is far enough in the future, I imagine by then we'll all be using something totally different. But making the code work as far out as you possibly can is good anyway, because it forces you to make the algorithm more robust. I made our_gmtime work as far out as I could (not to 2147483647 -- it turns out that we overflow a signed 64-bit millisecond count before then) and in the process was forced to come up with a technique for calculating the year that is just plain better, even in the date range we'll actually be using. >> Another advantage of not using struct tm is, you could report the >> milliseconds too. > > Uh.. we certainly don't want that for date certs, do we? Any other use > cases? I haven't done this part yet, but we do actually want milliseconds in date certs, or at least we want to accept and preserve them when they show up. I don't remember the exact details, but conversion from some foreign formats produces date certs with milliseconds in them, which is why the from-string constructor currently accepts and ignores digits after the decimal point. > Please bear in mind what the purpose for this change was/is: adding the > ability to get timestamp differences, adding and subtracting differences > to them. IMO this has already taken way too long and we should better > spend our dev-time on more relevant things. I want to mention four more things that we should try to get out of our date handling. With your changes and mine on top of them, we're very close, but some more work is still needed. I'm planning to do all of this, but if you feel inspired to do 'em first, please go ahead. First, when we print dates, we should print 'em in local time, not GMT, and we should offer the user the option to choose their preferred date format. This involves adding another as_* function that takes a strftime() format string (which higher layers will get from a Lua variable) and runs the internal representation through the system localtime() function. This is also another use for get_epoch_offset and is what I had in mind when I requested it, btw. Second, similarly, the --date option should operate in local time by default. The headache with this is that while mktime() is standard, filling in a 'struct tm' correctly is harder than one might think (as I mentioned before); the nonstandard 'tm_gmtoff' and 'tm_zone' fields may affect the result. (The Linux manpage doesn't say anything about them; glibc does have those fields but I *think* its mktime ignores them; the FreeBSD manpage mentions the fields but doesn't say what mktime does with them; I would want to survey other systems before actually doing this part.) Third, I do think we should request millisecond-accurate timestamps in now(), pass them through date certs, and print them when possible. This will be tricky in the face of the first one because strftime() and struct tm don't have millisecond fields -- I really don't want to implement my own strftime(). Maybe we could get away with a
Re: [Monotone-devel] Monotone 0.42: "peer [...] IO failed in confirmed state (success)"?
On Sun, Jan 4, 2009 at 10:22 AM, Markus Wanner wrote: > This has to do with your changes to netsync between 0.41 and 0.42 > (b0fcf9be.. by Timothy 2008-10-18, per mtn annotate). AFAICT select() is > saying the file descriptor is ready for reading, while reading from the > file descriptor returns 0 bytes. According to the man page for read(), > returning less than the requested amount of bytes is fine, only return > values < 0 signify an error. The select_tut man page clearly indicates, > that after getting zero bytes from read() or recv(), one should not call > select() on the fd anymore. > > I'm not overly familiar with netsync, but tried to fix it anyway. Please > review rev. f18abebd.. I'm not deeply familiar with netsync myself, but it looks good to me. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] "throw usage(); " or "N(); " for argument checking?
On Sun, Jan 4, 2009 at 10:30 AM, Timothy Brownawell wrote: > On Sun, 2009-01-04 at 18:41 +0100, Markus Wanner wrote: >> Timothy Brownawell wrote: >> > "N(false, message)" results in "throw informative_faulure(message)", the >> > question is what to throw rather than whether to throw. >> >> I'm with Timothy on that. These states are exceptional enough and much >> simpler to code. While "control loops" (why a loop, simple conditions >> would do, no?) clutter .. ehm.. exception handling a lot. Yes, especially in the present state where command-line errors are detected within the CMD() function, which is several levels down from the code that generates the usage message. It really is an exceptional transfer of control. >> > A command that does "throw usage()" gives the same result as calling >> > "mtn help ", printing full usage info to stderr, where N() >> > results in "mtn: misuse: " on stderr and will put a note in any >> > debug log. >> >> As long as the is maintained in case of "throw usage()", I'm >> fine. I dislike tools which just throw the complete usage page at me and >> let me figure myself. Some hint on what's wrong certainly helps. And >> that hint should survive, IMO. > > So I guess we should standardize on "throw usage()", but give usage a > what() and make the constructor take a message. I'm dubious about printing the full usage message on any command line mistake. Those are often long enough that they make the actual diagnostic scroll off the top of the terminal or at least be visually lost in a sea of chatter. What would be really good is if we could give customized usage advice based on the error, e.g. currently we have $ mtn ls mtn: misuse: no subcommand specified for 'ls' but 'mtn help ls' prints a 55-line message the relevant part of which is in the *middle.* It would be great if we could extract just the "subcommands of 'mtn ls'" part of that message and print it after the above diagnostic. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] monotone-0.41 compile failure with glibc(disabled-nls)
Hi, Philipp Gröschler wrote: > You can check with > # USE="-nls" emerge -av glibc > so that portage prints out what it would do. If it accepts the use flag, > the output should look like Thanks, that looks good. > If NLS still would be compiled in, try > # eselect profile list > and chose "hardened/linux/x86" (or whatever architecture is > appropriate). Not 100% sure if that helps, but on when I tried this on > my virtual box a few days ago, NLS was disabled globally. Disabling it > for only the glibc could get you into serious trouble, I guess. > Sometimes Gentoo is a little bit goatish ;-) Hehe.. yeah. I'll try the hardened variant, cannot hurt to have such a hardened buildbot... Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] monotone-0.41 compile failure with glibc(disabled-nls)
Markus Wanner schrieb: How do I build the glibc *without* it? Does the following help? # USE="-nls" emerge glibc You can check with # USE="-nls" emerge -av glibc so that portage prints out what it would do. If it accepts the use flag, the output should look like These are the packages that would be merged, in order: > Calculating dependencies... done! [ebuild R ] sys-libs/glibc-2.6.1 USE="gd (multilib) -debug (-hardened) -nls* (-selinux) " > Would you like to merge these packages? [Yes/No] Use flags in parentheses are overrided by the system profile. The asterisk behind "-nls" shows the difference to the currently installed version. My profile is "default/linux/amd64/2008.0/desktop". If NLS still would be compiled in, try # eselect profile list and chose "hardened/linux/x86" (or whatever architecture is appropriate). Not 100% sure if that helps, but on when I tried this on my virtual box a few days ago, NLS was disabled globally. Disabling it for only the glibc could get you into serious trouble, I guess. Sometimes Gentoo is a little bit goatish ;-) Good luck! Philipp ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] "throw usage(); " or "N(); " for argument checking?
On Sun, 2009-01-04 at 18:41 +0100, Markus Wanner wrote: > Hi, > > Timothy Brownawell wrote: > > "N(false, message)" results in "throw informative_faulure(message)", the > > question is what to throw rather than whether to throw. > > I'm with Timothy on that. These states are exceptional enough and much > simpler to code. While "control loops" (why a loop, simple conditions > would do, no?) clutter .. ehm.. exception handling a lot. > > > A command that does "throw usage()" gives the same result as calling > > "mtn help ", printing full usage info to stderr, where N() > > results in "mtn: misuse: " on stderr and will put a note in any > > debug log. > > As long as the is maintained in case of "throw usage()", I'm > fine. I dislike tools which just throw the complete usage page at me and > let me figure myself. Some hint on what's wrong certainly helps. And > that hint should survive, IMO. So I guess we should standardize on "throw usage()", but give usage a what() and make the constructor take a message. -- 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] monotone-0.41 compile failure with glibc(disabled-nls)
Hi, Philipp Gröschler wrote: > If you have app-portage/gentoolkit installed, try > # equery uses sys-libs/glibc > to see which use flags apply to your current glibc build. Thanks for this hint, glibc really is compiled with NLS support. How do I build the glibc *without* it? Does the following help? # USE="-nls" emerge glibc Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Monotone 0.42: "peer [...] IO failed in confirmed state (success)"?
Hello Timothy, Markus Wanner wrote: > Ralf S. Engelschall wrote: >> | mtn: peer monotone.ca IO failed in confirmed state (success) >> | mtn: successful exchange with monotone.ca > > I can reproduce this on a i386 FreeBSD 6.4 and will try to hunt the bug > - sometime this month. Thank you for reporting this. This has to do with your changes to netsync between 0.41 and 0.42 (b0fcf9be.. by Timothy 2008-10-18, per mtn annotate). AFAICT select() is saying the file descriptor is ready for reading, while reading from the file descriptor returns 0 bytes. According to the man page for read(), returning less than the requested amount of bytes is fine, only return values < 0 signify an error. The select_tut man page clearly indicates, that after getting zero bytes from read() or recv(), one should not call select() on the fd anymore. I'm not overly familiar with netsync, but tried to fix it anyway. Please review rev. f18abebd.. Unit tests work fine on Debian sid, FreeBSD 6.4 and Gentoo 2008.0 and the misleading error reported by Ralf has disappeared. Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Monotone 0.42: "peer [...] IO failed in confirmed state (success)"?
Hello Timothy, Markus Wanner wrote: > Ralf S. Engelschall wrote: >> | mtn: peer monotone.ca IO failed in confirmed state (success) >> | mtn: successful exchange with monotone.ca > > I can reproduce this on a i386 FreeBSD 6.4 and will try to hunt the bug > - sometime this month. Thank you for reporting this. This has to do with your changes to netsync between 0.41 and 0.42 (b0fcf9be.. by Timothy 2008-10-18, per mtn annotate). AFAICT select() is saying the file descriptor is ready for reading, while reading from the file descriptor returns 0 bytes. According to the man page for read(), returning less than the requested amount of bytes is fine, only return values < 0 signify an error. The select_tut man page clearly indicates, that after getting zero bytes from read() or recv(), one should not call select() on the fd anymore. I'm not overly familiar with netsync, but tried to fix it anyway. Please review rev. f18abebd.. Unit tests work fine on Debian sid, FreeBSD 6.4 and Gentoo 2008.0 and the misleading error reported by Ralf has disappeared. Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] "throw usage(); " or "N(); " for argument checking?
Hi, LeJacq, Jean Pierre wrote: > Two considerations: > > 1. N() can always be modified to provide an alternate implementation, >though I acknowledge that changing from throw semantics >would be problematic. For example, adding logging before the throw. Isn't this exactly what Timothy proposes? Clearer separation of the two. > 2. N() is not the best choice for handling this to begin with. Agreed. Timothy proposed using "throw usage();" instead, which is according to these two requests, AFAICT. Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] monotone-0.41 compile failure with glibc(disabled-nls)
Markus Wanner schrieb: Hm.. I'm unable to reproduce this issue on my virtual Gentoo 2008.0 box. I'm using these USE flags in /etc/make.conf: # manually prevent unneeded stuff USE="-kde -qt3 -qt4 -gtk -gnome -nls" ... (as long as I don't manually give --disable-nls). So I'm guessing my glibc is still compiled with nls. How do I check? Gentoo's sys-libs/glibc is "resistant" to many use flags, I am still trying to guess where this could be overridden. Recently I tried to compile it with "hardened" use flag, which wouldn't suceed until setting the portage profile to a hardened one. Seems like the system is protecting the user from messing around with the core libraries and the toolchain. Another flag which seems to be overridden is "nls" so it could definitely be that your glibc build still includes that. Just try # emerge --info and take a look at the listing of active useflags somewhere at the bottom of the output. If you have app-portage/gentoolkit installed, try # equery uses sys-libs/glibc to see which use flags apply to your current glibc build. Greetings! Philipp ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] "throw usage(); " or "N(); " for argument checking?
On Sunday 2009 January 04 11:41:46 Timothy Brownawell wrote:
> On Sun, 2009-01-04 at 11:24 -0500, LeJacq, Jean Pierre wrote:
> > On Saturday 2009 January 03 20:56:52 Timothy Brownawell wrote:
> > > Many commands check for eg the right number of arguments like so:
> > >
> > > if (args.size() != 3)
> > > throw usage(execid);
> > >
> > > where others do
> > >
> > > N(args.size() == 0,
> > > F("no arguments needed"));
> > >
> > >
> > > This ought to be made consistent, does anyone object to using the
> > > 'throw usage();' version everywhere?
> >
> > I recommend the inverse. Exceptions should be reserved for, well
> > "exceptional" situations. Validation of inputs doesn't fall into
> > this category and is more properly handled by normal control loops.
>
> "N(false, message)" results in "throw informative_faulure(message)", the
> question is what to throw rather than whether to throw.
Two considerations:
1. N() can always be modified to provide an alternate implementation,
though I acknowledge that changing from throw semantics
would be problematic. For example, adding logging before the throw.
2. N() is not the best choice for handling this to begin with.
--
JP
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] monotone-0.41 compile failure with glibc(disabled-nls)
Markus Wanner wrote: Daniel Black wrote: As per https://bugs.gentoo.org/show_bug.cgi?id=238540 monotone fails to compile when glibc is compiled with --disable-nls. This occures even when monotone is configured with ./configure --disable-nls. Hm.. I'm unable to reproduce this issue on my virtual Gentoo 2008.0 box. fwiw, I can see the same compile problem when configuring monotone with --disable-nls on (standard) debian lenny and fedora 10. - Thomas ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] "throw usage(); " or "N(); " for argument checking?
Hi, Timothy Brownawell wrote: > "N(false, message)" results in "throw informative_faulure(message)", the > question is what to throw rather than whether to throw. I'm with Timothy on that. These states are exceptional enough and much simpler to code. While "control loops" (why a loop, simple conditions would do, no?) clutter .. ehm.. exception handling a lot. > A command that does "throw usage()" gives the same result as calling > "mtn help ", printing full usage info to stderr, where N() > results in "mtn: misuse: " on stderr and will put a note in any > debug log. As long as the is maintained in case of "throw usage()", I'm fine. I dislike tools which just throw the complete usage page at me and let me figure myself. Some hint on what's wrong certainly helps. And that hint should survive, IMO. Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] monotone-0.41 compile failure with glibc(disabled-nls)
Daniel Black wrote: > As per https://bugs.gentoo.org/show_bug.cgi?id=238540 monotone fails to > compile when glibc is compiled with --disable-nls. This occures even when > monotone is configured with ./configure --disable-nls. Hm.. I'm unable to reproduce this issue on my virtual Gentoo 2008.0 box. I'm using these USE flags in /etc/make.conf: # manually prevent unneeded stuff USE="-kde -qt3 -qt4 -gtk -gnome -nls" I've rebuilt 'world' once, then recompiled glibc, gcc and gettext again, but still don't see the compilation errors. The tests suite runs through fine as well. What bugs me is, that ./configure still says: ... checking whether NLS is requested... yes ... (as long as I don't manually give --disable-nls). So I'm guessing my glibc is still compiled with nls. How do I check? Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] "throw usage(); " or "N(); " for argument checking?
On Sun, 2009-01-04 at 11:24 -0500, LeJacq, Jean Pierre wrote:
> On Saturday 2009 January 03 20:56:52 Timothy Brownawell wrote:
> > Many commands check for eg the right number of arguments like so:
> >
> > if (args.size() != 3)
> > throw usage(execid);
> >
> > where others do
> >
> > N(args.size() == 0,
> > F("no arguments needed"));
> >
> >
> > This ought to be made consistent, does anyone object to using the
> > 'throw usage();' version everywhere?
>
> I recommend the inverse. Exceptions should be reserved for, well
> "exceptional" situations. Validation of inputs doesn't fall into
> this category and is more properly handled by normal control loops.
"N(false, message)" results in "throw informative_faulure(message)", the
question is what to throw rather than whether to throw.
A command that does "throw usage()" gives the same result as calling
"mtn help ", printing full usage info to stderr, where N()
results in "mtn: misuse: " on stderr and will put a note in any
debug log.
--
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] "throw usage(); " or "N(); " for argument checking?
On Saturday 2009 January 03 20:56:52 Timothy Brownawell wrote:
> Many commands check for eg the right number of arguments like so:
>
> if (args.size() != 3)
> throw usage(execid);
>
> where others do
>
> N(args.size() == 0,
> F("no arguments needed"));
>
>
> This ought to be made consistent, does anyone object to using the
> 'throw usage();' version everywhere?
I recommend the inverse. Exceptions should be reserved for, well
"exceptional" situations. Validation of inputs doesn't fall into
this category and is more properly handled by normal control loops.
--
JP
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
