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

[Thomas Keller]

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.

>>> 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
> ?? 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.
>  * policy branches
>    - not even close to 2 months, more like a year or year and a half
>  * daggy refinement
>    - can be made compatible; not really started so longer than 2 months
>  * SSL for netsync
>    - can be made compatible; also not really started, so longer
>      than 2 months
>  * rename --guess (I think there's a branch out there for this)
>    - not a breaking change
>  * partial pull
>    - not started, way more than 2 months; wouldn't be a breaking change
>      in that fallback to an older netsync version is possible (but
>      partial pulls would only work with a recent enough server)
>  * get rid of die-die-die
>    - this would probalby require change the revision format, so it would
>      be a breaking change; but it's way longer than 2 months
>  * 'mountpoint' node type to replace merge_into_dir
>    - this would definitely require changing the revision format, and
>      would definitely take longer than 2 months
>  * a way to remove illegal files from history
>    - requires cooperation between client and server, would be a breaking
>      change; way longer than 2 months
>  * netsync preview
>    - not a breaking change; depending on what's in the preview it likely
>      wouldn't even affect the wire protocol at all

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

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

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?

>>> 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.
>>
>> I'm still up for a warning - what if you have a checked out workspace
>> and upgrade to the mtn version which disallows its particular naming?
>> You won't be able to do a single commit any longer.
> 
> That would be handled by permitting any branch name that already exists.

Point taken. You're of course right, we don't want to spit out warnings
everytime either...

> ...really, this whole thing is a bit silly. Nobody actually uses funny
> characters in their branch names, and even if you do you can substitute
> a '?' during sync (because netsync takes globs, and only the first '?'
> is treated specially) rather than looking up the hex code.

I played around with utf8 characters in branch names and that worked
reasonably well (beside that utf8 chars cannot be used in character
classes, but then again I just learned today that our globish class
supports character classes at all...) - so if utf8 works (with wildcards
even), then you're right, this discussion is academic.

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

>> +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?
>>
>>     mtn db kill_revision [REVID]
>>     mtn db kill_tag [TAG_NAME]
>>     mtn db kill_branch [BRANCH]
>>     mtn db rename_branch [OLD_NAME] [NEW_NAME]
> 
> These actually change (delete) sync-able data, and we want to make very
> explicit that these changes cannot be synced properly. These should all
> be used rarely enough that the extra typing isn't a problem.

This whole cleanup should probably be done completely independent from
the other issue above. Its mainly the inconsistent naming and
implementation we have for these commands which strike me here.

For example, we have a command to kill a single tag, a command to kill a
complete branch and a command to kill a certain revision. All these
commands have been implemented for very specific use cases, but don't
serve well for others.

E.g. if the user approved a revision for another branch, he cannot use
any of these to revert that locally. The same problem is true for
suspend certs, testresults, comments and everything else (except tags)..

Also the naming is somewhat stupid - yes, they're triggered locally
(just like everything else under db), so we might as well group all of
them in a special "local" group and skip the "_locally" suffix. The
explanation of the "local" group could make it very clear that using
these commands will not change anything remotely and might even bring
back things which have been killed once. And if spelling it out is not a
problem, why do we use kill_rev_locally and not kill_revision_locally?
Ok, this is just a minor nitpick - but it teases me every time I see it.


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 and change underscores to
dashes in the longer commands.

Thomas.

-- 
GPG-Key 0x160D1092 | address@hidden | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en

signature.asc
Description: OpenPGP digital signature