Ihor Radchenko wrote:
> Bob Proulx writes:
> > Also one of the good reasons to have it be "https" in both places is
> > because it is easy to match them up.  "http" matches with "http",
> > "https" matches with "https".
>
> That's what makes some users think that it is a typo.
> See https://list.orgmode.org/orgmode/[email protected]/

    git clone https://https.git.savannah.nongnu.org/git/org-mode.git

I mean there is already "git" in a zillion places in the line!  I
figured people would be desensitized to it.  :-}

>     git.git.savannah.gnu.org
>     https.git.savannah.gnu.org
>     http.git.savannah.gnu.org
>     gitweb.git.savannah.gnu.org
>     cgit.git.savannah.gnu.org
>
> Hmm. I was rather thinking about something like
>
> mirror.git.savannah.gnu.org
> mirror.cgit.savannah.gnu.org
> etc
>
> Not everything under the same name.

Ah, I see.  That flattens one layer of namespace hierarchy.

Remember that in Savannah we also have svn, hg, bzr, cvs too and all
of those will eventually be heading down the mirror path the same as
git.  In the future there might be new version control systems.  Who
knows what the future might bring?  Because there are only three magic
numbers in the universe: Zero, One, and Many.

One of the things I liked about namespacing everything under
*.git.sv.gnu.org is that all git stuff was under that namespace.  And
all Subversion stuff would be down *.svn.sv.gnu.org namespace.  And so
on with the others.  This allows viewvc to be in viewvc.svn.sv.gnu.org
in a different namespace than viewvc.cvs.sv.gnu.org and all be
regularly mapped.  And who knows what new tools will be created for
git which might not have git in the name as all of the current ones
do.  In that future case not being namespaced means it would need to
be irregularly named to avoid name collisions with the other things.

Naming things is hard!

I am torn.  One of the complaints about the longer names is that the
entire hostname gets to be quite long.  I want to avoid thrashing
everyone changing names too often.  I want to avoid needing to support
multiple parallel services that are almost the same but not.  Four of
those above are web server configurations (currently Nginx) and we
make heavy use of include files to avoid the copy-paste anti-pattern
trying to keep the configuration DRY but that also creates a complex
and confusing spaghetti configuration.  After having exposed the
current URLs I would hate to kill them off changing to a new naming
strategy.  I would hate to keep both of them due to the configuration
complexity that produces.

Aarrrgh!

Bob

Reply via email to