Thomas Keller <m...@thomaskeller.biz> writes: > Am 10.06.2010 13:52, schrieb Stephen Leake: >> Thomas Keller <m...@thomaskeller.biz> writes: >> >>> Am 10.06.2010 09:49, schrieb Stephen Leake: >>>> This is a reasonable approach, but personally I would prefer an error (I >>>> always prefer errors over warnings; it's just too easy to miss >>>> warnings). >>> >>> See my earlier mail - how do we handle old workspaces with then invalid >>> branch names? I don't like the idea of bailing out with an error for >>> every workspace command just because the used branch option is >>> wrong... >> >> Yes; the warning or error should only occur on the creation of a new >> branch. > > The "creation" is probably too late. If the error has a validation > nature, it has to happen very early, i.e. before anything important took > place.
I have not looked at this in detail, but I'm assuming we can check very early whether the operation will create a new branch, and do the check. For example, in 'mtn commit --branch foo', we can check right at the beginning whether foo already exists as a branch, and if not, error out, before doing anything else. > See, I just don't want to issue a lot of spaghetti code for this thing Right. > and maybe we're doing a nice bikeshed discussion here anyways because > 99% of the monotone users would not be affected by either, the warning > or the error. Right. >>>> This is another case where it would be best to allow the user to set the >>>> default they want, but be able to override that default easily. >>>> >>>> That requires overridable options; supporting '--foo ... --no-foo'. >>>> >>>> Overridable options has come up a few times before; maybe we should make >>>> that a required feature for 1.0? I have not looked into how hard that >>>> would be. >>> >>> See also my earlier mail - where do we want to draw the line? >> >> I'm suggesting we draw the line to include overridable options. But we'd >> have to be ok with saying "this is too hard" after seriously looking at >> it. > > Seriously, is this really so important? I'm asking if you (and others) think it is important. I'll take this as "no, we should not require this feature for 1.0". > there are many, many other feature requests open for a longer time. Perhaps it would be good to post a list here, and have a semi-formal vote on whether they should be required for 1.0 > Many of them should be considered more important than options handling > and even than the whole URI discussion, so where do we draw the line > if they speak up as well? We draw the line by reaching consensus after informed discussion. > ...and we'd effectively have the old status quo - don't go for 1.0 at > all, because you never have all 1.0 features ready :) We can make a formal statement now about what is actually required for 1.0. I'm happy saying "no new features are required for 1.0; go for it". But we should at least think about it a little more. -- -- Stephe _______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel