[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] Re: netsync connection info cleanup
From: |
Timothy Brownawell |
Subject: |
Re: [Monotone-devel] Re: netsync connection info cleanup |
Date: |
Thu, 10 Jun 2010 17:15:25 -0500 |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100515 Icedove/3.0.4 |
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
- Re: [Monotone-devel] Re: netsync connection info cleanup, (continued)
- Re: [Monotone-devel] Re: netsync connection info cleanup, Thomas Keller, 2010/06/09
- Re: [Monotone-devel] Re: netsync connection info cleanup, Timothy Brownawell, 2010/06/09
- Re: [Monotone-devel] Re: netsync connection info cleanup, Timothy Brownawell, 2010/06/09
- Re: [Monotone-devel] Re: netsync connection info cleanup, Stephen Leake, 2010/06/10
- Re: [Monotone-devel] Re: netsync connection info cleanup, Thomas Keller, 2010/06/10
- Re: [Monotone-devel] Re: netsync connection info cleanup, Stephen Leake, 2010/06/10
- Re: [Monotone-devel] Re: netsync connection info cleanup, Thomas Keller, 2010/06/10
- Re: [Monotone-devel] Re: netsync connection info cleanup, Stephen Leake, 2010/06/11
- Message not available
- Re: [Monotone-devel] Re: netsync connection info cleanup, Timothy Brownawell, 2010/06/10
- Re: [Monotone-devel] Re: netsync connection info cleanup, Thomas Keller, 2010/06/10
- Re: [Monotone-devel] Re: netsync connection info cleanup,
Timothy Brownawell <=