[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 11:48:20 -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 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
- Re: [Monotone-devel] Re: netsync connection info cleanup, (continued)
- Re: [Monotone-devel] Re: netsync connection info cleanup, hendrik, 2010/06/09
- 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 <=
- Re: [Monotone-devel] Re: netsync connection info cleanup, Thomas Keller, 2010/06/10
- Re: [Monotone-devel] Re: netsync connection info cleanup, Timothy Brownawell, 2010/06/10