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

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

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

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

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


--
Timothy

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