Re: [Monotone-devel] Re: netsync connection info cleanup

[Stephen Leake]

Thomas Keller <address@hidden> writes:

> Am 10.06.2010 13:52, schrieb Stephen Leake:
>> Thomas Keller <address@hidden> 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