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

[Stephen Leake]

Thomas Keller <address@hidden> writes:

> Am 10.06.2010 09:49, schrieb Stephen Leake:
>> Timothy Brownawell <address@hidden> writes:
>> 
>>>> Hrm - should we really disallow them by default? Another option could be
>>>> to just issue a warning and let the user go ahead. Wireing in the code
>>>> which errors out in an invalid case and correctly rolling back might be
>>>> cumbersome, given the fact that we have a couple of places from which we
>>>> create branch certs (approve, commit -b, cert, automate cert, setup,
>>>> import, cvs_import, ...)
>>>
>>> A warning after the fact doesn't help much, by the time you see it
>>> you've already got your hard-to-work-with branch name. Unless we want
>>> to add a 'db rename_branch_locally' or similar to make this fixable
>>> after-the-fact, and then point that out in the warning. That might
>>> actually be the better solution.
>> 
>> 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.

>> 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.

> What is reasonable to expect as development outcome for the next, say,
> 4 weeks in June and July, where its hot everywhere...? 

I don't think we should make it a time issue, as long as people are
making reasonable progress on each feature we agree to hold the release for.

> Do we really want to block everything else until then?

That's what branches are for. We could continue the current release
pattern (not switch to 0.99) until all 1.0 features are ready.

However, I think overrideable options is the only such feature mentioned
so far? Have I missed something?

And I'm not saying we must hold 1.0 for this. I think it would be good,
but I'm willing to go along if the consensus is to not wait for it.

Since the gnuopts package provides overridable options, lots of
applications have them. So it will be perceived as a flaw that mtn
doesn't.

-- 
-- Stephe