Re: [Monotone-devel] Re: netsync connection info cleanup
Thomas Keller writes: > Am 10.06.2010 13:52, schrieb Stephen Leake: >> Thomas Keller writes: >> >>> Am 10.06.2010 09:49, schrieb Stephen Leake: This is a reasonable approach, but personally I would prefer an error (I always prefer errors over warnings; it's just too easy to miss warnings). >>> >>> See my earlier mail - how do we handle old workspaces with then invalid >>> branch names? I don't like the idea of bailing out with an error for >>> every workspace command just because the used branch option is >>> wrong... >> >> Yes; the warning or error should only occur on the creation of a new >> branch. > > The "creation" is probably too late. If the error has a validation > nature, it has to happen very early, i.e. before anything important took > place. I have not looked at this in detail, but I'm assuming we can check very early whether the operation will create a new branch, and do the check. For example, in 'mtn commit --branch foo', we can check right at the beginning whether foo already exists as a branch, and if not, error out, before doing anything else. > See, I just don't want to issue a lot of spaghetti code for this thing Right. > and maybe we're doing a nice bikeshed discussion here anyways because > 99% of the monotone users would not be affected by either, the warning > or the error. Right. This is another case where it would be best to allow the user to set the default they want, but be able to override that default easily. That requires overridable options; supporting '--foo ... --no-foo'. Overridable options has come up a few times before; maybe we should make that a required feature for 1.0? I have not looked into how hard that would be. >>> >>> See also my earlier mail - where do we want to draw the line? >> >> I'm suggesting we draw the line to include overridable options. But we'd >> have to be ok with saying "this is too hard" after seriously looking at >> it. > > Seriously, is this really so important? I'm asking if you (and others) think it is important. I'll take this as "no, we should not require this feature for 1.0". > there are many, many other feature requests open for a longer time. Perhaps it would be good to post a list here, and have a semi-formal vote on whether they should be required for 1.0 > Many of them should be considered more important than options handling > and even than the whole URI discussion, so where do we draw the line > if they speak up as well? We draw the line by reaching consensus after informed discussion. > ...and we'd effectively have the old status quo - don't go for 1.0 at > all, because you never have all 1.0 features ready :) We can make a formal statement now about what is actually required for 1.0. I'm happy saying "no new features are required for 1.0; go for it". But we should at least think about it a little more. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: netsync connection info cleanup
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
Re: [Monotone-devel] Re: netsync connection info cleanup
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-
Re: [Monotone-devel] Re: netsync connection info cleanup
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
Re: [Monotone-devel] Re: netsync connection info cleanup
Am 10.06.2010 13:52, schrieb Stephen Leake: > Thomas Keller writes: > >> Am 10.06.2010 09:49, schrieb Stephen Leake: >>> This is a reasonable approach, but personally I would prefer an error (I >>> always prefer errors over warnings; it's just too easy to miss >>> warnings). >> >> See my earlier mail - how do we handle old workspaces with then invalid >> branch names? I don't like the idea of bailing out with an error for >> every workspace command just because the used branch option is >> wrong... > > Yes; the warning or error should only occur on the creation of a new > branch. The "creation" is probably too late. If the error has a validation nature, it has to happen very early, i.e. before anything important took place. See, I just don't want to issue a lot of spaghetti code for this thing and maybe we're doing a nice bikeshed discussion here anyways because 99% of the monotone users would not be affected by either, the warning or the error. >>> This is another case where it would be best to allow the user to set the >>> default they want, but be able to override that default easily. >>> >>> That requires overridable options; supporting '--foo ... --no-foo'. >>> >>> Overridable options has come up a few times before; maybe we should make >>> that a required feature for 1.0? I have not looked into how hard that >>> would be. >> >> See also my earlier mail - where do we want to draw the line? > > I'm suggesting we draw the line to include overridable options. But we'd > have to be ok with saying "this is too hard" after seriously looking at > it. Seriously, is this really so important? I don't want to hold you off, no, I even encourage you to work in this area, but the overridable options discussion just popped up recently (mainly because of advanced automate use) and there are many, many other feature requests open for a longer time. Many of them should be considered more important than options handling and even than the whole URI discussion, so where do we draw the line if they speak up as well? >> What is reasonable to expect as development outcome for the next, say, >> 4 weeks in June and July, where its hot everywhere...? > > I don't think we should make it a time issue, as long as people are > making reasonable progress on each feature we agree to hold the release for. > >> Do we really want to block everything else until then? > > That's what branches are for. We could continue the current release > pattern (not switch to 0.99) until all 1.0 features are ready. ...and we'd effectively have the old status quo - don't go for 1.0 at all, because you never have all 1.0 features ready :) > However, I think overrideable options is the only such feature mentioned > so far? Have I missed something? > > And I'm not saying we must hold 1.0 for this. I think it would be good, > but I'm willing to go along if the consensus is to not wait for it. > > Since the gnuopts package provides overridable options, lots of > applications have them. So it will be perceived as a flaw that mtn > doesn't. As I said, if you would go for it and its doable in a reasonable time frame, go for it. Otherwise I'd rather leave that for 1.1 or later (when its finished). Thomas. -- GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | 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 ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: netsync connection info cleanup
Thomas Keller writes: > Am 10.06.2010 09:49, schrieb Stephen Leake: >> Timothy Brownawell writes: >> Hrm - should we really disallow them by default? Another option could be to just issue a warning and let the user go ahead. Wireing in the code which errors out in an invalid case and correctly rolling back might be cumbersome, given the fact that we have a couple of places from which we create branch certs (approve, commit -b, cert, automate cert, setup, import, cvs_import, ...) >>> >>> 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. >> >> This is a reasonable approach, but personally I would prefer an error (I >> always prefer errors over warnings; it's just too easy to miss >> warnings). > > See my earlier mail - how do we handle old workspaces with then invalid > branch names? I don't like the idea of bailing out with an error for > every workspace command just because the used branch option is > wrong... Yes; the warning or error should only occur on the creation of a new branch. >> This is another case where it would be best to allow the user to set the >> default they want, but be able to override that default easily. >> >> That requires overridable options; supporting '--foo ... --no-foo'. >> >> Overridable options has come up a few times before; maybe we should make >> that a required feature for 1.0? I have not looked into how hard that >> would be. > > See also my earlier mail - where do we want to draw the line? I'm suggesting we draw the line to include overridable options. But we'd have to be ok with saying "this is too hard" after seriously looking at it. > What is reasonable to expect as development outcome for the next, say, > 4 weeks in June and July, where its hot everywhere...? I don't think we should make it a time issue, as long as people are making reasonable progress on each feature we agree to hold the release for. > Do we really want to block everything else until then? That's what branches are for. We could continue the current release pattern (not switch to 0.99) until all 1.0 features are ready. However, I think overrideable options is the only such feature mentioned so far? Have I missed something? And I'm not saying we must hold 1.0 for this. I think it would be good, but I'm willing to go along if the consensus is to not wait for it. Since the gnuopts package provides overridable options, lots of applications have them. So it will be perceived as a flaw that mtn doesn't. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: netsync connection info cleanup
Am 10.06.2010 09:49, schrieb Stephen Leake: > Timothy Brownawell writes: > >>> Hrm - should we really disallow them by default? Another option could be >>> to just issue a warning and let the user go ahead. Wireing in the code >>> which errors out in an invalid case and correctly rolling back might be >>> cumbersome, given the fact that we have a couple of places from which we >>> create branch certs (approve, commit -b, cert, automate cert, setup, >>> import, cvs_import, ...) >> >> 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. > > This is a reasonable approach, but personally I would prefer an error (I > always prefer errors over warnings; it's just too easy to miss > warnings). See my earlier mail - how do we handle old workspaces with then invalid branch names? I don't like the idea of bailing out with an error for every workspace command just because the used branch option is wrong... > This is another case where it would be best to allow the user to set the > default they want, but be able to override that default easily. > > That requires overridable options; supporting '--foo ... --no-foo'. > > Overridable options has come up a few times before; maybe we should make > that a required feature for 1.0? I have not looked into how hard that > would be. See also my earlier mail - where do we want to draw the line? What is reasonable to expect as development outcome for the next, say, 4 weeks in June and July, where its hot everywhere...? Do we really want to block everything else until then? Thomas. -- GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | 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 ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: netsync connection info cleanup
Timothy Brownawell writes: >> Hrm - should we really disallow them by default? Another option could be >> to just issue a warning and let the user go ahead. Wireing in the code >> which errors out in an invalid case and correctly rolling back might be >> cumbersome, given the fact that we have a couple of places from which we >> create branch certs (approve, commit -b, cert, automate cert, setup, >> import, cvs_import, ...) > > 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. This is a reasonable approach, but personally I would prefer an error (I always prefer errors over warnings; it's just too easy to miss warnings). The error can be detected as soon as the branch name is specified, so I don't see why backing out would be a problem. We have to add code in the same places to get the warning. Hmm. I guess that's not true; the warning code could be deeper in, so that could be fewer places. This is another case where it would be best to allow the user to set the default they want, but be able to override that default easily. That requires overridable options; supporting '--foo ... --no-foo'. Overridable options has come up a few times before; maybe we should make that a required feature for 1.0? I have not looked into how hard that would be. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: netsync connection info cleanup
On 06/09/2010 10:02 PM, Timothy Brownawell wrote: On 06/09/2010 06:34 PM, Thomas Keller wrote: We could still disallow '+' if we'd want to make inclusion also explicit, but some people disagreed on this. Personally I won't mind. Well, the reason for '+' is more that a '+' in a url translates to a space after urldecoding. So for example 'mtn://foo.com/bar?abc+def' would translate to an include pattern of "abc def" and to get an include pattern of "abc+def" you'd need 'mtn://foo.com/bar?abc%2Bdef'. Which would be annoying to remember, especially if you don't typically work with urls. ...hm. Except that our urldecode is broken and doesn't actually do this. Which could be annoying for people who do work with urls regularly and do put spaces in their branch names for some reason. Looking at this further (rfc 3986), '+' is a "reserved character" that *can* have a special meaning in a particular scheme but is not generally interpreted as a space or anything else special. So nevermind then, plusses are fine and our urldecode doesn't need fixing (and the only confused people will be those who are somewhat foggy on the difference between URLs in general and http URLs in particular). -- Timothy Free public monotone hosting: http://mtn-host.prjek.net ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: netsync connection info cleanup
On 06/09/2010 06:34 PM, Thomas Keller wrote: Am 09.06.10 19:01, schrieb Timothy Brownawell: On 04/28/2010 06:06 AM, Thomas Keller wrote: Am 28.04.2010 12:36, schrieb Thomas Moschny: Am Sun, 18 Apr 2010 20:49:37 +0200 schrieb Thomas Keller: Secondly, I'd actively deprecate any branch name which does not match the following regular expression, i.e. by throwing a warning when a branch cert which a different value is created: ^([\w\d]+([-][\w\d]+)*)(\.[\w\d]+([-][\w\d]+)*)*$ Sounds good to me, but maybe we have to ask our users, whether that'd be ok for them. And we should still allow them to use other branch names if they wish so (because technically, there's no need for such a restriction). Depending on the actual URI scheme we'll be using, we can further adapt the regular expression above, like f.e. if the URI scheme will look like this: scheme://u...@host/db?include,-exclude,include This is in the nvm.connection_info_cleanup branch now. Are there any objections to merging it? It doesn't include any string changes. I understand that it might be a good idea to have this in before 0.99/1.0.0 because it breaks BC a bit (well, if anybody used this feature at all) and because you need to know the proper URI scheme for usher as well, but I was just about to start hacking on this branch again and wanted to do a couple of other things on my way. So I wouldn't mind to see the whole thing in 1.1.0 or later. What sort of other things, more user-visible changes or internal code hygiene? 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. this should be sufficient I think (untested): ^[^-,*][^,*]+$ I think we also don't like '+' and '%' due to urlencoding. Apropos '+' - this shouldn't be needed - I forgot to exclude whitespace above. I agree with '%' and would also add '?'. The above regex also disallowed single char branch names, so this should work better: ^[^-,*%\s][^,*%\s]*$ We could still disallow '+' if we'd want to make inclusion also explicit, but some people disagreed on this. Personally I won't mind. Well, the reason for '+' is more that a '+' in a url translates to a space after urldecoding. So for example 'mtn://foo.com/bar?abc+def' would translate to an include pattern of "abc def" and to get an include pattern of "abc+def" you'd need 'mtn://foo.com/bar?abc%2Bdef'. Which would be annoying to remember, especially if you don't typically work with urls. ...hm. Except that our urldecode is broken and doesn't actually do this. Which could be annoying for people who do work with urls regularly and do put spaces in their branch names for some reason. Any objections to requiring an --allow-discouraged-branch-names option to create branch certs that don't match /^[^-,*+%][^,*+%]*$/? Hrm - should we really disallow them by default? Another option could be to just issue a warning and let the user go ahead. Wireing in the code which errors out in an invalid case and correctly rolling back might be cumbersome, given the fact that we have a couple of places from which we create branch certs (approve, commit -b, cert, automate cert, setup, import, cvs_import, ...) 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 guess this would have to be after this upcoming release, due to the new translatable strings it would have. Yes, definitely. Thomas. -- Timothy Free public monotone hosting: http://mtn-host.prjek.net ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: netsync connection info cleanup
Am 09.06.10 19:01, schrieb Timothy Brownawell: > On 04/28/2010 06:06 AM, Thomas Keller wrote: >> Am 28.04.2010 12:36, schrieb Thomas Moschny: >>> Am Sun, 18 Apr 2010 20:49:37 +0200 >>> schrieb Thomas Keller: >>> Secondly, I'd actively deprecate any branch name which does not match the following regular expression, i.e. by throwing a warning when a branch cert which a different value is created: ^([\w\d]+([-][\w\d]+)*)(\.[\w\d]+([-][\w\d]+)*)*$ >>> >>> Sounds good to me, but maybe we have to ask our users, whether that'd >>> be ok for them. And we should still allow them to use other branch names >>> if they wish so (because technically, there's no need for such a >>> restriction). >> >> Depending on the actual URI scheme we'll be using, we can further adapt >> the regular expression above, like f.e. if the URI scheme will look like >> this: >> >> scheme://u...@host/db?include,-exclude,include > > This is in the nvm.connection_info_cleanup branch now. Are there any > objections to merging it? It doesn't include any string changes. I understand that it might be a good idea to have this in before 0.99/1.0.0 because it breaks BC a bit (well, if anybody used this feature at all) and because you need to know the proper URI scheme for usher as well, but I was just about to start hacking on this branch again and wanted to do a couple of other things on my way. So I wouldn't mind to see the whole thing in 1.1.0 or later. >> this should be sufficient I think (untested): >> >> ^[^-,*][^,*]+$ > > I think we also don't like '+' and '%' due to urlencoding. Apropos '+' - this shouldn't be needed - I forgot to exclude whitespace above. I agree with '%' and would also add '?'. The above regex also disallowed single char branch names, so this should work better: ^[^-,*%\s][^,*%\s]*$ We could still disallow '+' if we'd want to make inclusion also explicit, but some people disagreed on this. Personally I won't mind. > Any > objections to requiring an --allow-discouraged-branch-names option to > create branch certs that don't match /^[^-,*+%][^,*+%]*$/? Hrm - should we really disallow them by default? Another option could be to just issue a warning and let the user go ahead. Wireing in the code which errors out in an invalid case and correctly rolling back might be cumbersome, given the fact that we have a couple of places from which we create branch certs (approve, commit -b, cert, automate cert, setup, import, cvs_import, ...) > I guess this would have to be after this upcoming release, due to the > new translatable strings it would have. Yes, definitely. Thomas. -- GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | 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 ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: netsync connection info cleanup
On 06/09/2010 12:13 PM, hend...@topoi.pooq.com wrote: On Wed, Jun 09, 2010 at 12:01:10PM -0500, Timothy Brownawell wrote: I think we also don't like '+' and '%' due to urlencoding. Any objections to requiring an --allow-discouraged-branch-names option to create branch certs that don't match /^[^-,*+%][^,*+%]*$/? I guess this would have to be after this upcoming release, due to the new translatable strings it would have. Perhaps branch names that are already in the repository should be allowed without this option? Yeah, that sounds like a good idea. -- Timothy Free public monotone hosting: http://mtn-host.prjek.net ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: netsync connection info cleanup
On Wed, Jun 09, 2010 at 12:01:10PM -0500, Timothy Brownawell wrote: > > I think we also don't like '+' and '%' due to urlencoding. Any > objections to requiring an --allow-discouraged-branch-names option to > create branch certs that don't match /^[^-,*+%][^,*+%]*$/? > > I guess this would have to be after this upcoming release, due to the > new translatable strings it would have. Perhaps branch names that are already in the repository should be allowed without this option? -- hendrik ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: netsync connection info cleanup
On 04/28/2010 06:06 AM, Thomas Keller wrote: Am 28.04.2010 12:36, schrieb Thomas Moschny: Am Sun, 18 Apr 2010 20:49:37 +0200 schrieb Thomas Keller: Secondly, I'd actively deprecate any branch name which does not match the following regular expression, i.e. by throwing a warning when a branch cert which a different value is created: ^([\w\d]+([-][\w\d]+)*)(\.[\w\d]+([-][\w\d]+)*)*$ Sounds good to me, but maybe we have to ask our users, whether that'd be ok for them. And we should still allow them to use other branch names if they wish so (because technically, there's no need for such a restriction). Depending on the actual URI scheme we'll be using, we can further adapt the regular expression above, like f.e. if the URI scheme will look like this: scheme://u...@host/db?include,-exclude,include This is in the nvm.connection_info_cleanup branch now. Are there any objections to merging it? It doesn't include any string changes. this should be sufficient I think (untested): ^[^-,*][^,*]+$ I think we also don't like '+' and '%' due to urlencoding. Any objections to requiring an --allow-discouraged-branch-names option to create branch certs that don't match /^[^-,*+%][^,*+%]*$/? I guess this would have to be after this upcoming release, due to the new translatable strings it would have. "mtn ls branches | grep -v -E '^(\w+(-\w+)*)(\.\w+(-\w+)*)*$'" shows only one branch that doesn't match in my local copy of the monotone db (prjek.net:tester). Wouldn't be a problem with the above naming. Thomas. -- Timothy Free public monotone hosting: http://mtn-host.prjek.net ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: netsync connection info cleanup
On Wed, Apr 28, 2010 at 09:41:08AM -0600, Derek Scherger wrote: > On Wed, Apr 28, 2010 at 1:34 AM, Thomas Keller wrote: > > > > > +1/2 - this is similar to my last proposal (with ":" as separators, but > > I'd accept "," as well) - but the mandatory "?" still strikes me. Do you > > see any way to avoid "?" for the 90% use case (sync a single branch > > without wildcards from / to a remote database)? > > > > I haven't followed this thread terribly carefully so this may be a rehash of > something earlier (apologies in advance if it is). Branches can be > considered "things that exist within a database" so the idea of a hierarchy > from database to branch is somewhat reasonable. Following this, a url like > > mtn://host/database/branch > > might be workable and can avoid the need for a ? separator. Things might get > awkward when you try and extend this to include more than one branch or > several branch patterns though. There's a syntactic ambiguity here in knowing where the database name (which might contain slashes) ends and the branch name starts. On a system where files and directories can't have the same names, it can be resolved semantically. But on systems like, say. DEC VMS, there might be a problem. Does the syntax here actually need to be system-independent? I admit, it would be nice... . -- hendrik ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: netsync connection info cleanup
On Wed, Apr 28, 2010 at 1:34 AM, Thomas Keller wrote: > > +1/2 - this is similar to my last proposal (with ":" as separators, but > I'd accept "," as well) - but the mandatory "?" still strikes me. Do you > see any way to avoid "?" for the 90% use case (sync a single branch > without wildcards from / to a remote database)? > I haven't followed this thread terribly carefully so this may be a rehash of something earlier (apologies in advance if it is). Branches can be considered "things that exist within a database" so the idea of a hierarchy from database to branch is somewhat reasonable. Following this, a url like mtn://host/database/branch might be workable and can avoid the need for a ? separator. Things might get awkward when you try and extend this to include more than one branch or several branch patterns though. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: netsync connection info cleanup
On Wed, Apr 28, 2010 at 5:14 AM, Thomas Moschny wrote: > > > "mtn ls branches | grep -v -E '^(\w+(-\w+)*)(\.\w+(-\w+)*)*$'" > > > shows only one branch that doesn't match in my local copy of the > > > monotone db (prjek.net:tester). > > > > And what would you do with that branch if this were to become a > > restriction? > > I said I'd agree with the idea of *warning* the user (not *disallowing* > usage of such branch names), I also said I think there's no technical > need to restrict branch names - besides obvious things like \0, and > given there's a way to quote characters if necessary (e.g. using URL > quoting). > For the record, when I was working on the git_export stuff the prjek.net:tester branch name was considered invalid by git and it was necessary to map this name to something else for git to accept it. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: netsync connection info cleanup
Am Wed, 28 Apr 2010 02:50:09 -0400 schrieb hend...@topoi.pooq.com: > On Wed, Apr 28, 2010 at 12:36:59PM +0200, Thomas Moschny wrote: > > Am Sun, 18 Apr 2010 20:49:37 +0200 > > schrieb Thomas Keller : > > > > > Secondly, I'd actively deprecate any branch name which does not > > > match the following regular expression, i.e. by throwing a > > > warning when a branch cert which a different value is created: > > > > > >^([\w\d]+([-][\w\d]+)*)(\.[\w\d]+([-][\w\d]+)*)*$ > > > > Sounds good to me, but maybe we have to ask our users, whether > > that'd be ok for them. And we should still allow them to use other > > branch names if they wish so (because technically, there's no need > > for such a restriction). > > > > "mtn ls branches | grep -v -E '^(\w+(-\w+)*)(\.\w+(-\w+)*)*$'" > > shows only one branch that doesn't match in my local copy of the > > monotone db (prjek.net:tester). > > And what would you do with that branch if this were to become a > restriction? I said I'd agree with the idea of *warning* the user (not *disallowing* usage of such branch names), I also said I think there's no technical need to restrict branch names - besides obvious things like \0, and given there's a way to quote characters if necessary (e.g. using URL quoting). - Thomas ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: netsync connection info cleanup
Am 28.04.2010 08:50, schrieb hend...@topoi.pooq.com: > On Wed, Apr 28, 2010 at 12:36:59PM +0200, Thomas Moschny wrote: >> Am Sun, 18 Apr 2010 20:49:37 +0200 >> schrieb Thomas Keller : >> >>> Secondly, I'd actively deprecate any branch name which does not match >>> the following regular expression, i.e. by throwing a warning when a >>> branch cert which a different value is created: >>> >>>^([\w\d]+([-][\w\d]+)*)(\.[\w\d]+([-][\w\d]+)*)*$ >> >> Sounds good to me, but maybe we have to ask our users, whether that'd >> be ok for them. And we should still allow them to use other branch names >> if they wish so (because technically, there's no need for such a >> restriction). >> >> "mtn ls branches | grep -v -E '^(\w+(-\w+)*)(\.\w+(-\w+)*)*$'" shows only >> one branch that doesn't match in my local copy of the monotone db >> (prjek.net:tester). > > And what would you do with that branch if this were to become a > restriction? Well, we could still handle branches like this, but we'd enforce the usage of url encoding, i.e. if a branch name looks like this -foo*,bar we would be able to handle it when it is given so: %2Dfoo%2Cbar%2A And to avoid that the user would have to encode that by hand, we'd make the "compatibility" arguments and options BRANCH_PATTERN [--exclude=...] to convert the given value to the internal, url-escaped version. Thomas. -- GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | 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 ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: netsync connection info cleanup
Am 28.04.2010 12:36, schrieb Thomas Moschny: > Am Sun, 18 Apr 2010 20:49:37 +0200 > schrieb Thomas Keller : > >> Secondly, I'd actively deprecate any branch name which does not match >> the following regular expression, i.e. by throwing a warning when a >> branch cert which a different value is created: >> >>^([\w\d]+([-][\w\d]+)*)(\.[\w\d]+([-][\w\d]+)*)*$ > > Sounds good to me, but maybe we have to ask our users, whether that'd > be ok for them. And we should still allow them to use other branch names > if they wish so (because technically, there's no need for such a > restriction). Depending on the actual URI scheme we'll be using, we can further adapt the regular expression above, like f.e. if the URI scheme will look like this: scheme://u...@host/db?include,-exclude,include this should be sufficient I think (untested): ^[^-,*][^,*]+$ > "mtn ls branches | grep -v -E '^(\w+(-\w+)*)(\.\w+(-\w+)*)*$'" shows only > one branch that doesn't match in my local copy of the monotone db > (prjek.net:tester). Wouldn't be a problem with the above naming. Thomas. -- GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | 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 ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: netsync connection info cleanup
Am 28.04.2010 08:42, schrieb hend...@topoi.pooq.com: > On Tue, Apr 27, 2010 at 04:54:01PM -0700, Zack Weinberg wrote: >> So, how about this? >> >> >> protocol://u...@server.host.name/path/to/database?include,include,-exclude,-exclude >> >> should work equally well for mtn (with usher), ssh, and file. Without >> usher, you just leave out the /path part. > > Does this mean that, with usher, it will now be mandatory to specify the > database explicitly? That usher will no longer be able to make > decisions based on the branch name(s) involved? And that, to a user, > usher-based monotones will look different from bare monotones? No, this is merely an extension to usher (which iirc has already been partially implemented by Tim) to have a third way to pick a database for usher where DNS is not possible and branch pattern uniqueness might not always be given. Thomas. -- GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | 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 ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: netsync connection info cleanup
On Wed, Apr 28, 2010 at 12:36:59PM +0200, Thomas Moschny wrote: > Am Sun, 18 Apr 2010 20:49:37 +0200 > schrieb Thomas Keller : > > > Secondly, I'd actively deprecate any branch name which does not match > > the following regular expression, i.e. by throwing a warning when a > > branch cert which a different value is created: > > > >^([\w\d]+([-][\w\d]+)*)(\.[\w\d]+([-][\w\d]+)*)*$ > > Sounds good to me, but maybe we have to ask our users, whether that'd > be ok for them. And we should still allow them to use other branch names > if they wish so (because technically, there's no need for such a > restriction). > > "mtn ls branches | grep -v -E '^(\w+(-\w+)*)(\.\w+(-\w+)*)*$'" shows only > one branch that doesn't match in my local copy of the monotone db > (prjek.net:tester). And what would you do with that branch if this were to become a restriction? -- hendrik ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: netsync connection info cleanup
On Tue, Apr 27, 2010 at 04:54:01PM -0700, Zack Weinberg wrote: > On Tue, Apr 27, 2010 at 4:42 PM, Timothy Brownawell > wrote: > > > > Is the occasional backslash really that bad? '%' conflicts with urlencoding > > (and '*' would only actually glob things if you have some really weirdly > > named files), and '?' is probably necessary for file/ssh sync. > > I think it's more important to avoid characters that are meaningful in > URLs (*especially* %) than to avoid characters that are meaningful to > the shell. People expect to have to quote URLs. Also, I don't like / > as a separator when it's not traversing a directory-like hierarchy. > > So, how about this? > > > protocol://u...@server.host.name/path/to/database?include,include,-exclude,-exclude > > should work equally well for mtn (with usher), ssh, and file. Without > usher, you just leave out the /path part. Does this mean that, with usher, it will now be mandatory to specify the database explicitly? That usher will no longer be able to make decisions based on the branch name(s) involved? And that, to a user, usher-based monotones will look different from bare monotones? -- hendrik ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: netsync connection info cleanup
Am Sun, 18 Apr 2010 20:49:37 +0200 schrieb Thomas Keller : > Secondly, I'd actively deprecate any branch name which does not match > the following regular expression, i.e. by throwing a warning when a > branch cert which a different value is created: > >^([\w\d]+([-][\w\d]+)*)(\.[\w\d]+([-][\w\d]+)*)*$ Sounds good to me, but maybe we have to ask our users, whether that'd be ok for them. And we should still allow them to use other branch names if they wish so (because technically, there's no need for such a restriction). "mtn ls branches | grep -v -E '^(\w+(-\w+)*)(\.\w+(-\w+)*)*$'" shows only one branch that doesn't match in my local copy of the monotone db (prjek.net:tester). -Thomas ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: netsync connection info cleanup
Am Wed, 28 Apr 2010 09:40:23 +0200 schrieb Thomas Keller : > I think I have to find another shell... > > $ echo mtn://foo.com#foo > zsh: no matches found: mtn://foo.com#foo > > So if its only zsh and whatever I try here needs escaping anyways, we > can simply stick to the more common "?" then... "set nonomatch" in ~/.zshrc does help: [tho...@localhost ~]% echo mtn://foo.com#foo mtn://foo.com#foo Best, Thomas ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: netsync connection info cleanup
Am 28.04.2010 07:25, schrieb Derek Scherger: > On Tue, Apr 27, 2010 at 5:54 PM, Zack Weinberg wrote: > >> On Tue, Apr 27, 2010 at 4:42 PM, Timothy Brownawell >> wrote: >>> >>> Is the occasional backslash really that bad? '%' conflicts with >> urlencoding >>> (and '*' would only actually glob things if you have some really weirdly >>> named files), and '?' is probably necessary for file/ssh sync. >> >> I think it's more important to avoid characters that are meaningful in >> URLs (*especially* %) than to avoid characters that are meaningful to >> the shell. People expect to have to quote URLs. Also, I don't like / >> as a separator when it's not traversing a directory-like hierarchy. >> > > Agreed, on all counts. > > >> So, how about this? >> >> protocol:// >> u...@server.host.name/path/to/database?include,include,-exclude,-exclude >> >> should work equally well for mtn (with usher), ssh, and file. Without >> usher, you just leave out the /path part. >> > > +1 (nice and simple) Ok, I see I get overruled here ;) >> (Also, ~ in the path part should absolutely have the 'go to home >> directory' semantic.) >> > > Agreed here too. > > This proposal doesn't change the meaning of any URL-special characters which > I think is important. Overloading % + ? = or & would be bad as people > generally know what they mean in the context of a URL. We could consider > using the fragment character # in place of the query string separator > character ? but that's probably splitting hairs. This is a shell-special > character too (for comments) but it doesn't seem to apply if there's > non-whitespace immediately preceding it. I think I have to find another shell... $ echo mtn://foo.com#foo zsh: no matches found: mtn://foo.com#foo So if its only zsh and whatever I try here needs escaping anyways, we can simply stick to the more common "?" then... Thomas. -- GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | 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 ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: netsync connection info cleanup
Am 28.04.2010 02:00, schrieb Timothy Brownawell: > On 04/27/2010 06:54 PM, Zack Weinberg wrote: >> On Tue, Apr 27, 2010 at 4:42 PM, Timothy >> Brownawell wrote: >>> >>> Is the occasional backslash really that bad? '%' conflicts with >>> urlencoding >>> (and '*' would only actually glob things if you have some really weirdly >>> named files), and '?' is probably necessary for file/ssh sync. >> >> I think it's more important to avoid characters that are meaningful in >> URLs (*especially* %) than to avoid characters that are meaningful to >> the shell. People expect to have to quote URLs. Also, I don't like / >> as a separator when it's not traversing a directory-like hierarchy. > > Huh, hadn't really considered the "overloading '/'" aspect. It does seem > slightly bad now that you mention it. > >> So, how about this? >> >> >> protocol://u...@server.host.name/path/to/database?include,include,-exclude,-exclude >> > > +1 +1/2 - this is similar to my last proposal (with ":" as separators, but I'd accept "," as well) - but the mandatory "?" still strikes me. Do you see any way to avoid "?" for the 90% use case (sync a single branch without wildcards from / to a remote database)? Thomas. -- GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | 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 ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: netsync connection info cleanup
On Tue, Apr 27, 2010 at 5:54 PM, Zack Weinberg wrote: > On Tue, Apr 27, 2010 at 4:42 PM, Timothy Brownawell > wrote: > > > > Is the occasional backslash really that bad? '%' conflicts with > urlencoding > > (and '*' would only actually glob things if you have some really weirdly > > named files), and '?' is probably necessary for file/ssh sync. > > I think it's more important to avoid characters that are meaningful in > URLs (*especially* %) than to avoid characters that are meaningful to > the shell. People expect to have to quote URLs. Also, I don't like / > as a separator when it's not traversing a directory-like hierarchy. > Agreed, on all counts. > So, how about this? > > protocol:// > u...@server.host.name/path/to/database?include,include,-exclude,-exclude > > should work equally well for mtn (with usher), ssh, and file. Without > usher, you just leave out the /path part. > +1 (nice and simple) > > (Also, ~ in the path part should absolutely have the 'go to home > directory' semantic.) > Agreed here too. This proposal doesn't change the meaning of any URL-special characters which I think is important. Overloading % + ? = or & would be bad as people generally know what they mean in the context of a URL. We could consider using the fragment character # in place of the query string separator character ? but that's probably splitting hairs. This is a shell-special character too (for comments) but it doesn't seem to apply if there's non-whitespace immediately preceding it. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: netsync connection info cleanup
On 04/27/2010 06:54 PM, Zack Weinberg wrote: On Tue, Apr 27, 2010 at 4:42 PM, Timothy Brownawell wrote: Is the occasional backslash really that bad? '%' conflicts with urlencoding (and '*' would only actually glob things if you have some really weirdly named files), and '?' is probably necessary for file/ssh sync. I think it's more important to avoid characters that are meaningful in URLs (*especially* %) than to avoid characters that are meaningful to the shell. People expect to have to quote URLs. Also, I don't like / as a separator when it's not traversing a directory-like hierarchy. Huh, hadn't really considered the "overloading '/'" aspect. It does seem slightly bad now that you mention it. So, how about this? protocol://u...@server.host.name/path/to/database?include,include,-exclude,-exclude +1 should work equally well for mtn (with usher), ssh, and file. Without usher, you just leave out the /path part. (Also, ~ in the path part should absolutely have the 'go to home directory' semantic.) zw -- Timothy Free public monotone hosting: http://mtn-host.prjek.net ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: netsync connection info cleanup
On Tue, Apr 27, 2010 at 4:42 PM, Timothy Brownawell wrote: > > Is the occasional backslash really that bad? '%' conflicts with urlencoding > (and '*' would only actually glob things if you have some really weirdly > named files), and '?' is probably necessary for file/ssh sync. I think it's more important to avoid characters that are meaningful in URLs (*especially* %) than to avoid characters that are meaningful to the shell. People expect to have to quote URLs. Also, I don't like / as a separator when it's not traversing a directory-like hierarchy. So, how about this? protocol://u...@server.host.name/path/to/database?include,include,-exclude,-exclude should work equally well for mtn (with usher), ssh, and file. Without usher, you just leave out the /path part. (Also, ~ in the path part should absolutely have the 'go to home directory' semantic.) zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: netsync connection info cleanup
Am 18.04.10 23:11, schrieb Zack Weinberg: > I don't have any feedback on this stuff myself, but I want to mention > that over a year ago, Roland McGrath posted some complaints about the > mtn:// URI schema being either broken or not useful as designed -- it > was never clear to me which, because I don't know how it's supposed to > work. You might want to dig back through the list archives and see if > you can't address his concerns as long as you're messing with this > stuff. I think you're referring back to this one here: http://www.mail-archive.com/monotone-devel@nongnu.org/msg11805.html I quickly skimmed over the discussion and it seems that his major complaint was that we have no means to select a database in our URI scheme until now, something which Tim wants to address by allowing mtn://monotone.ca/database-like uris. Thomas. -- GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | 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 ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: netsync connection info cleanup
I don't have any feedback on this stuff myself, but I want to mention that over a year ago, Roland McGrath posted some complaints about the mtn:// URI schema being either broken or not useful as designed -- it was never clear to me which, because I don't know how it's supposed to work. You might want to dig back through the list archives and see if you can't address his concerns as long as you're messing with this stuff. zw On Sun, Apr 18, 2010 at 11:49 AM, Thomas Keller wrote: > Am 18.04.10 04:34, schrieb Timothy Brownawell: >> On 04/15/2010 07:59 AM, Thomas Keller wrote: >>> However there is a bug in our parse_uri() implementation: If no scheme >>> (f.e. mtn://) is given, it treats the string as path rather than as >>> hostname. This leads to the problem that the scheme-less default server >>> setting we store in the db vars is not treated correctly and that a host >>> which is entered by the user is now also parsed wrongly. >>> As I said, I'd rather change the implementation of parse_uri than >>> forcing the user to pull "mtn://monotone.ca" instead of just >>> "monotone.ca"... >> >> This should work now. parse_uri() will check for things that look like >> only a hostname or ip address and maybe a port, and skip most of the logic. >> >> It also uses everything before the query string in the db vars, and also >> uses that for the 'peer' string in the network session. This is what >> gets sent to the usher, so giving >> mtn://monotone.ca/foobar?include=... >> would send "mtn://monotone.ca/foobar" to the usher where it currently >> sends only the hostname (and the normal way of "mtn sy monotone.ca ..." >> would still send just the hostname), which should make it possible to >> use usher with neither wildcard dns nor pattern-based dispatch. > > There are still a couple of quirks in the url parsing code - f.e. > path-like (invalid) URIs like the following one are accepted (it will > only fail if no default branch pattern is stored in the DB): > > mtn://monotone.ca/monotone/net.venge.monotone\ > /-net.venge.monotone.guitone > > which end up creating completly wrong default server entries. I think we > should define first what we want to allow and how it should look like > here. A small nuisance is f.e. that the "?" in the URI makes problems on > some shells (at least zsh), so you need to quote the complete string. > We've "supported" that use case halfwhat in the past by not using "&" as > query separator, but "/", but I think we can further improve this. > > The following URIs are currently supported: > > mtn://monotone.ca > mtn://monotone.ca/monotone > mtn://monotone.ca?foo.bar > mtn://monotone.ca?foo.bar*/-foo.bar.baz > mtn://monotone.ca/monotone?foo.bar > mtn://monotone.ca/monotone?foo.bar*/-foo.bar.baz > mtn://monotone.ca?include=foo.bar > mtn://monotone.ca?include=foo.bar*/exclude=foo.bar.baz > mtn://monotone.ca/monotone?include=foo.bar > mtn://monotone.ca/monotone?include=foo.bar*/exclude=foo.bar.baz > > The first unfortunate thing here is that we have to support two > different syntaxes, one time you can omit "include=" and replace > "exclude=" with a "-" and one time these can be given (probably because > we advertise that people could use weird branch name patterns which > don't follow the reverse dns scheme almost everybody uses, but this > doesn't seem to work correct either, try f.e. > "mtn://monotone.ca/monotone?include=foo/bar/baz*/exclude=foo/bar/baz/bla"). > > The second unfortunate thing is that the "short" syntax, while being > less verbose, still needs quoting because of "?" as the query separator > and "*" for branch expansion. > > > So how should we continue? I think we should pick _one_ syntax and stick > to that, and I'd vote for the simple one > > mtn://monotone.ca?foo.bar*/-foo.bar.baz > > but with a few modifications so it would look like this: > > mtn://monotone.ca/foo.bar%/-foo.bar.baz > > (or explicitely mtn://monotone.ca/+foo.bar%/-foo.bar.baz) > > Here no comand line quoting is needed at all and the SQL-like "%" > wildcard should be recognizable as well. > > Secondly, I'd actively deprecate any branch name which does not match > the following regular expression, i.e. by throwing a warning when a > branch cert which a different value is created: > > ^([\w\d]+([-][\w\d]+)*)(\.[\w\d]+([-][\w\d]+)*)*$ > > (test script to play around: http://pastebin.ca/1866605) > > This way we ensure that a branch name later does not conflict with the > URI separator nor with the wildcard character nor with the negation we > need for branch exclusion in our URI scheme. > > Thirdly I'd unify the way includes and excludes are defined for netsync > commands. I'd deprecate the "SERVER BRANCH [--exclude=PATTERN [...]]" > options (but would leave them available and convert them to the internal > representation with "%" as wildcard f.e.) and I'd make the new URI > available for all commands (currently clone does not support the old > URIs f.e.). > > > Lastly, th
