[pacman-dev] The great VCS packages overhaul of 2015

[Allan McRae]

On 13/03/12 21:53, Dan McGee wrote:
> On Tue, Mar 13, 2012 at 7:41 AM, Florian Pritz <bluewind at xinu.at> wrote:
>> On 13.03.2012 04:58, Allan McRae wrote:
>>> 1) URL:
>>> There were previous patches to the mailing list that never really got
>>> finished, but I think we were fairly happy with this syntax:
>>>
>>> source=(git://projects.archlinux.org/pacman.git)
>>> source=(git@@http://projects.archlinux.org/git/pacman.git)
>>>
>>> Does it make any sense to allow the "::" syntax here?  i.e.
>>> source=(git@@dirname::http://projects.archlinux.org/git/pacman.git)
>>
>> If you want to allow multiple sources of the same project, please don't
>> clone them into multiple directories. You'd just duplicate all objects
>> they share (which could be many).
>>
>> Better cd into the one you already have and simply add a new remote.
> I don't think this was the case anyone was talking about here. More
> like sources from:
> git://code.example.com/project.git
> git://code.example.com/project-extras.git
> 
>> I don't like the @@ and :: syntax. Maybe
>> "git://remotename//http://projects.archlinux.org/git/pacman.git"? That
>> way we can simply look for "git://" and also easily figure out if there
>> is a remote name or not. "//" should also be a safe delimiter because in
>> the URL it would be collapsed to "/" anyway.
> Heck no, minus -1000. We are **not** reinventing a URL syntax. This is
> confusing, misleading, and awful. Look at this:
>     git://remotename//git://projects.archlinux.org/pacman.git
> 
> I don't even know what remotename is (but if that can contain a '/',
> my eyes will really bleed). The double URL specifier (using the same
> protocol twice!!) is likely not allowable or recommended by
> http://tools.ietf.org/html/rfc3986.
> 
> If you are trying to stick with URI/URL format, I'd much rather see
> git+http:// in this case, which is a lot like the 'svn+ssh://'
> protocol you can use, etc. And then use fragment identifiers perhaps
> (RFC 3986, 3.5, '#branchname') to identify the branch name.

Hmm...  good idea using the fragment identifier for specifying the
branch/tag/commit to checkout.  Being inspired by how pypi uses these to
provide checksums, could I even suggest:

<url>#branch=maint
<url>#tag=v4.0.1
<url>#commit=f42ad345

This gives full clarity to what is being specified an allows for
potential cases where branches and tags have the same name and we could
provide multiple options, semicolon separated, if needed (obviously not
for git, but maybe for another VSC system).

Allan