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

2010-06-11 Thread Stephen Leake 
Thomas Keller m...@thomaskeller.biz writes:

 Am 10.06.2010 13:52, schrieb Stephen Leake:
 Thomas Keller m...@thomaskeller.biz 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

2010-06-10 Thread Stephen Leake 
Timothy Brownawell tbrow...@prjek.net 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

2010-06-10 Thread Thomas Keller 
Am 10.06.2010 09:49, schrieb Stephen Leake:
 Timothy Brownawell tbrow...@prjek.net 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

2010-06-10 Thread Stephen Leake 
Thomas Keller m...@thomaskeller.biz writes:

 Am 10.06.2010 09:49, schrieb Stephen Leake:
 Timothy Brownawell tbrow...@prjek.net 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

2010-06-10 Thread 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

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

2010-06-10 Thread 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

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

2010-06-10 Thread Timothy Brownawell 

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

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

2010-06-09 Thread 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 Kellerm...@thomaskeller.biz:


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

2010-06-09 Thread hendrik 
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

2010-06-09 Thread Timothy Brownawell 

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

2010-06-09 Thread Thomas Keller 
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 Kellerm...@thomaskeller.biz:

 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

2010-06-09 Thread Timothy Brownawell 

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 Kellerm...@thomaskeller.biz:


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

2010-06-09 Thread Timothy Brownawell 

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

2010-04-29 Thread hendrik 
On Wed, Apr 28, 2010 at 09:41:08AM -0600, Derek Scherger wrote:
 On Wed, Apr 28, 2010 at 1:34 AM, Thomas Keller m...@thomaskeller.biz 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

2010-04-28 Thread Thomas Keller 
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
 Brownawelltbrow...@prjek.net  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

2010-04-28 Thread Thomas Keller 
Am 28.04.2010 07:25, schrieb Derek Scherger:
 On Tue, Apr 27, 2010 at 5:54 PM, Zack Weinberg za...@panix.com wrote:
 
 On Tue, Apr 27, 2010 at 4:42 PM, Timothy Brownawell tbrow...@prjek.net
 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

2010-04-28 Thread Thomas Moschny 
Am Wed, 28 Apr 2010 09:40:23 +0200
schrieb Thomas Keller m...@thomaskeller.biz:

 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

2010-04-28 Thread Thomas Moschny 
Am Sun, 18 Apr 2010 20:49:37 +0200
schrieb Thomas Keller m...@thomaskeller.biz:

 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

2010-04-28 Thread hendrik 
On Tue, Apr 27, 2010 at 04:54:01PM -0700, Zack Weinberg wrote:
 On Tue, Apr 27, 2010 at 4:42 PM, Timothy Brownawell tbrow...@prjek.net 
 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

2010-04-28 Thread hendrik 
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 m...@thomaskeller.biz:
 
  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

2010-04-28 Thread Thomas Keller 
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

2010-04-28 Thread Thomas Keller 
Am 28.04.2010 12:36, schrieb Thomas Moschny:
 Am Sun, 18 Apr 2010 20:49:37 +0200
 schrieb Thomas Keller m...@thomaskeller.biz:
 
 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

2010-04-28 Thread Thomas Keller 
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 m...@thomaskeller.biz:

 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

2010-04-28 Thread Thomas Moschny 
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 m...@thomaskeller.biz:
  
   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

2010-04-28 Thread Derek Scherger 
On Wed, Apr 28, 2010 at 5:14 AM, Thomas Moschny thomas.mosc...@gmx.dewrote:

   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

2010-04-28 Thread Derek Scherger 
On Wed, Apr 28, 2010 at 1:34 AM, Thomas Keller m...@thomaskeller.biz 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

2010-04-27 Thread Zack Weinberg 
On Tue, Apr 27, 2010 at 4:42 PM, Timothy Brownawell tbrow...@prjek.net 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

2010-04-27 Thread Timothy Brownawell 

On 04/27/2010 06:54 PM, Zack Weinberg wrote:

On Tue, Apr 27, 2010 at 4:42 PM, Timothy Brownawelltbrow...@prjek.net  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

2010-04-27 Thread Derek Scherger 
On Tue, Apr 27, 2010 at 5:54 PM, Zack Weinberg za...@panix.com wrote:

 On Tue, Apr 27, 2010 at 4:42 PM, Timothy Brownawell tbrow...@prjek.net
 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

2010-04-18 Thread 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.

zw

On Sun, Apr 18, 2010 at 11:49 AM, Thomas Keller m...@thomaskeller.biz 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, the only thing which has not yet been determined is how we can
 represent the server notion for usher - clearly this would conflict with
 the