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

[Timothy Brownawell]

On 06/10/2010 02:36 PM, Thomas Keller wrote:
> Am 10.06.10 18:48, schrieb Timothy Brownawell:
> > On 06/10/2010 04:45 AM, Thomas Keller wrote:
> > > Am 10.06.2010 05:02, schrieb Timothy Brownawell:
> >
> > > > What sort of other things, more user-visible changes or internal code
> > > > hygiene?
> > >
> > > Both, actually:
> > >
> > > * cleanup the connection info handling mess
> > > * remove the code for the other include / exclude variants with
> > > "include=" and "exclude="
> > > * discourage branch names which conflict the new uri scheme as discussed
> > > either with a warning or an error
> > > * let clone accept mtn:// uris
> > > * deprecate SERVER [BRANCH [--exclude=PATTERN [...]]] arguments to push
> > > / pull / sync - I'd then include code to fall back on already existing
> > > branch patterns if f.e. a user only enters mtn://some.server instead of
> > > mtn://some.server?some.branch
> >
> > We have "automate {push,pull,sync}" now, so the second and last items
> > would I think be incompatible automate changes and therefore a major
> > version change. And releasing 2.0 very soon after 1.0 would probably get
> > people to look at us funny...
>
> Right, thats why I'd just deprecate them - i.e. they are still fully
> workable, but we say we remove that in 2.0 and we're using the URIs
> everywhere, in the documentation, in the wiki, etc. pp. This kind of
> deprecation should have no visible effect in the UI nor in automate.

OK, that makes sense.

> > > > Right now mtn:// sync doesn't work at all, and it really would
> > > > be nice for 1.0 to support non-hacky virtual hosting without needing a
> > > > special DNS setup.
> > >
> > > I'm a little torn between theee options here - release an unplanned 0.48
> > > in the meantime to no longer block finished things and get your work
> > > into trunk before we hit 0.99, let 0.99 wait until the above work has
> > > been finished and just following the planned path and get the work
> > > into 1.1.
> > > I don't want to change the plan too often. What if other people suddenly
> > > want to get a certain thing done before the glorious "1.0" hits the
> > > street? Where do I stop? Opinions anybody?
> > >
> > > To not mess too much with the "masterplan" I tend to wait for 0.99 a
> > > little longer...
> >
> > What *breaking* (ie, major-version change; automate major number bump or
> > non-negotiable network incompatibility) changes do we have that can
> > reasonably be expected to be ready in less than, say, 2 months? (Any
> > major-version changes not ready in time would have to wait... probably
> > at least a year, in the absence of any brown-paper-bag design bugs.
> > Minor-version changes can of course happen whenever.)
> >
> > ->  getting rid of SERVER [PATTERN ... [--exclude=PATTERN ...]]
> >     - this is a breaking change, and should be doable in that time
> > ->  get rid of long-form include=... exclude=... syntax for uri syncs
> >     - breaking change; doable in 2 months

So these two are non-breaking due to being just a deprecation instead of 
removal.

> > ?? fixing mtn:// sync; passing 'path' info to usher
> >     - not really a breaking change; but releasing 1.0 without this
> >       would be expected to reduce hosting choices/quality for as
> >       long as 1.0 stays in general use. This is ready now.
> > ->  extended selectors
> >     - not a breaking change? (actually I guess it is; you need to escape
> >       some additional rarely-used characters). This is ready now.
> > ->  deprecating some branch names
> >     - there is no "automate commit", but at least the error version
> >       would probably mean changing the behavior of "automate cert"
> >       and I'm not sure if the warning version would count as a change.
> >       But as noted below I think now that this is silly and we probably
> >       don't want to bother with it. If we do do this, it's doable
> >       in 2 months.

> Nice list - is this directly from your personal todo...? :)

Some of the things are, but I also checked the wiki and current branches 
and Pidgin's "monotone limitations" page.

> I won't comment on each single one - just two things:
>
> 1) We don't care about free-text out-of-band output, so if some command
> issues a warning or a progress message more than before or differently,
> no whatsoever version bump should be introduced. This is not because
> we're all lazy, but because this wouldn't be managable at all (imagine
> an string fix deep in the code path which is executed by a normal and an
> automate command).

Makes sense.

> 2) I acknowledge that a couple of people seem to be somewhat overrun by
> the whole 1.0 discussion - and I'm almost convinced to release a 0.48
> within the next few days and skip the 1.0 plans until the majority of
> people (i.e. not just me apparently, I don't get much positive
> feedback...) have a good feeling about it. Could we then at least have
> some terminated goal, f.e. early this fall, to make 1.0 finally arrive then?

I'd like to see what other breaking changes people have in mind, that 
can be done reasonably soon. Say we take through this weekend to collect 
all breaking changes that can hit some deadline (2 months, or the end of 
September, or something), and then do 1.0 at the deadline or earlier if 
everything on the list is in.

It looks like we probably do want one more release, to at least get in 
string changes for branch name depracation/kill_cert_locally and 
extended selectors and maybe landing nvm.rename-guess, depending on what 
status it's in.

> [...]
> Let us just warn on new branch certs and add some generic handling for
> wrong certs (see below).

OK.

> > > +1 for the rename_branch_locally, but I'd use the opportunity and remove
> > > the ugly "_locally" suffix from a couple of commands and clean-up their
> > > names - after all, all commands under the "db" command are executed
> > > locally, right?

   <tommyd> tbrownaw: I thought it might be even easier to have a
   generic kill_cert_locally [-r SELECTOR] CERT_NAME command

That would be very good, but it should also optionally take a value so 
you can for example kill one of a revisions many branch certs. I think 
we'd also want to make sure 'cert' works with a multi-valued selector, 
so you could do things like
   mtn cert b:somebranch branch otherbranch
   mtn db kill_cert_locally -r b:somebranch branch somebranch

> I'd probably add another todo in your list above, something which came
> up a couple of times, lately from Derek: We should cleanup the somewhat
> uncontrolled growth of the command naming

I'm guessing this would take more than a couple months to figure out, so 
it would mean either delaying 1.0 to late fall / winter or waiting for 2.0 .

> and change underscores to
> dashes in the longer commands.

Changing the underscores to dashes I think was actually about accepting 
either interchangably. So that would be a minor-version change, doable 
whenever.

--
Timothy

Free public monotone hosting: http://mtn-host.prjek.net