<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Mar 21, 2015 at 6:19 PM, Ryan McElroy <span dir="ltr"><<a href="mailto:rm@fb.com" target="_blank">rm@fb.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><div><div class="h5">
<div>On 3/16/2015 9:04 PM, Gregory Szorc
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">On Sun, Mar 15, 2015 at 12:55 PM, Matt Mackall <span dir="ltr"><<a href="mailto:mpm@selenic.com" target="_blank">mpm@selenic.com</a>></span>
wrote:<br>
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>On Sat,
2015-03-14 at 22:18 -0700, Gregory Szorc wrote:<br>
> On Wed, Mar 11, 2015 at 3:55 PM, Matt Mackall <<a href="mailto:mpm@selenic.com" target="_blank">mpm@selenic.com</a>> wrote:<br>
><br>
> > I agree that the odds of people having foo.bar
paths is probably 100%:<br>
> > it is after all how DNS names are structured.
Unfortunately it's also<br>
> > how our config namespace is structured.<br>
> ><br>
><br>
> I think it is important to distinguish between
option names, option values,<br>
> and command line arguments.<br>
><br>
> For option values and command line arguments,
absolutely we'll have periods<br>
> because of hostnames. However, I believe our logic
there is to first<br>
> attempt to parse those values as URLs, then fall
back to a filesystem-local<br>
> path if a scheme isn't present. (Follow-up idea:
have Mercurial store URLs<br>
> in more situations because bare strings are more
ambiguous.)<br>
<br>
</span>$ hg push <a href="http://selenic.com" target="_blank">selenic.com</a><br>
pushing to <a href="http://selenic.com" target="_blank">selenic.com</a><br>
abort: repository <a href="http://selenic.com" target="_blank">selenic.com</a>
not found!<br>
<br>
No, we treat bare hostnames as local paths.<br>
<br>
But I think people will actually have hostname-like
entries as path<br>
_keys_, not values (where they won't actually work). And
then use those<br>
path keys on the command line. For instance, I can imagine
a project<br>
split between <a href="http://foo.org" target="_blank">foo.org</a> (open
source) and <a href="http://foo.com" target="_blank">foo.com</a> (with
commercial bits)<br>
and someone having both URLs in their ~/.hgrc. Or perhaps
the domain is<br>
integral to the verbal identity like "<a href="http://healthcare.gov" target="_blank">healthcare.gov</a>" (you'd never refer<br>
to it as just "healthcare" or "healthcaregov"). Picture a
web design<br>
shop that's deploying to its dozens of clients' sites by
domain name...<br>
<span><br>
> If we limit discussion to option values, I'm still
not convinced supporting<br>
> periods is important.<br>
><br>
><br>
> > > I think a clean, one-time break is
better.<br>
> ><br>
> > I greatly prefer zero-time breaks, but I don't
have a great alternative<br>
> > suggestion. We do have a bit of precedent in
the [auth] section though.<br>
> > Perhaps we can do:<br>
> ><br>
> > [paths]<br>
> > old.style = some/path<br>
> > new.style.path = some/other/pass<br>
> > new.style.option = foo<br>
> > bogus.option = foo<br>
> ><br>
> > Here, hg paths would list:<br>
> ><br>
> > old.style<br>
> > new.style<br>
> > bogus.option<br>
> ><br>
> > (..and we'd also change clone to make the
default path setting<br>
> > "default.path".)<br>
> ><br>
><br>
> This is an interesting idea. I like how it avoids
ambiguity between whether<br>
> an entry is a path or isn't. However, it still has
concerns:<br>
><br>
> * Long-term Mercurial users now have to convert to
a new config style to<br>
> use advanced options.<br>
<br>
</span>Yeah, but I think that's pretty minor.<br>
<span><br>
> * Potential for collision between user-defined path
names and per-path<br>
> options.<br>
<br>
</span>I think the potential only exists for paths of the
form "foo.bar.path",<br>
which signals "hey, we have a path with options named
foo.bar". So if<br>
you happen to want to name something with a ".path"
suffix, you'll now<br>
have to name it ".path.path". Not perfect, but not fatal.<br>
<span><br>
> I imagine a user will see they can add ".pushrev"
to a path and produce a<br>
> snippet like:<br>
><br>
> [paths]<br>
> central = <a href="https://hg.mozilla.org/mozilla-central" target="_blank">https://hg.mozilla.org/mozilla-central</a><br>
> central.pushrev = .<br>
><br>
> Without the ".path", this situation is ambiguous.
Do we then have to<br>
> examine common option prefixes and do some kind of
disambiguation to figure<br>
> out the user's intent?<br>
<br>
</span>Yeah, this won't work in my scheme, it'll define
two paths. A path X is<br>
only newstyle with options if X.path is defined. So any
examples of<br>
central.pushrev would need to include central.path.<br>
<span><br>
> What about something like this:<br>
><br>
> [paths]<br>
> repo.prod = <a href="https://prod.hg.example.com/repo" target="_blank">https://prod.hg.example.com/repo</a><br>
> repo.prod.pushrev = .<br>
> repo.dev = <a href="https://dev.hg.example.com/repo" target="_blank">https://dev.hg.example.com/repo</a><br>
><br>
> I still think unsupported periods in path names is
looking pretty<br>
> reasonable. So does separate [path.x] sections.<br>
<br>
</span>What's unsupported periods again? That's no dots in
path keys?<br>
</blockquote>
<div><br>
</div>
<div>Dots in path keys.<br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I don't think that's going to work. I don't know that
path.x sections<br>
work either, because the config format actually already
treats dots as<br>
hierarchy separators and [foo] is just a special case for
the tree top<br>
level. In other words [foo]bar.x and [foo.bar]x are both
aliases for<br>
foo.bar.x.<br>
</blockquote>
<div><br>
</div>
<div>I'm not so sure about that. I *think* config.config is
preserving all content in [SECTION]. I don't see anywhere
where dots are getting collapsed.<br>
<br>
</div>
</div>
(Pdb) import config<br>
(Pdb) conf = config.config()<br>
(Pdb) conf.parse('test', '[path.foo]\nbar = True')<br>
(Pdb) pp conf._data<br>
{'path.foo': {'bar': 'True'}}<br>
<br>
</div>
<div class="gmail_extra">I think passing the sections list down
to the ui.paths constructor will work. I did something similar
in the first version of this patch series (I was foolishly
using ":" as the delimiter - "[path:foo]") and it seemed to
work fine.<br>
</div>
</div>
<br>
</blockquote>
<br></div></div>
Kind of late to the party here, but it didn't seem that this had
been decided yet so I thought I'd throw out a thought I had while
reading this discussion:<br>
<br>
Add a new section, called [uris]. In it, we can do it in an
"enhanced" way. Probably we would enforce more rules on the URIs --
eg, make them unambiguous and fully qualified so "mirror" style
clones (a future feature) would be able to copy them and know they
point to the same thing (this is just an idea, a real implementation
would figure out what the "right" rules are).<br>
<br>
[uris]<br>
default.uri = <a href="http://smf.io/hgremotenames" target="_blank">http://smf.io/hgremotenames</a><br>
default.pushrev = .<br>
default.newoption = foo<br>
<br>
Thoughts? If I missed the memo and this is already decided in a
different direction, I'm happy to be informed of that as well.<span class="HOEnZb"><font color="#888888"></font></span></div></blockquote><div><br></div><div>Aside from the potential confusion around multiple sections (which we may have anyway if we go with [path.X]), I like it! As a bonus, this is relatively simple to implement (just union entries inside the new "paths" API).<br><br></div><div>As a bikeshed, should we consider "remotes" instead of "uris?" That jives with "remotenames." It's also very Git-like. But I'm not sure if that's good or bad.<br></div></div></div></div>