Re: Improvements to ‘debian/watch’ for fetching from VCS
Raphael Geissert <atomo64+debian@gmail.com> writes:
> Ben Finney wrote:
>
> > I'd prefer, if the information is to be encoded in the URL, that
> > the URL should remain useable as-is with the VCS tool itself.
> >
> > I know that's possible for ‘svn+http://’;, but it's not possible
> > for ‘bzr+http://’; if the files are merely stored on plain HTTP
> > (i.e. without a Bazaar server driving it). What about others?
>
> How does bzr recognise whether it should use http or not?
I don't understand the question. I'll try to answer what might be the
question; if this doesn't answer you, please re-phrase.
Bazaar can use HTTP as a transport for file-level operations; that's
what a ‘http://’; URL specifies. The server doesn't need to be anything
except a static HTTP server.
Bazaar can alternatively use HTTP as a transport for Bazaar “smart
server” commands, requiring a Bazaar server to be answering at the
other end. That's what a ‘bzr+http://’; URL specifies.
> uscan would of course hand over that part of the job to the $VCS
> tool, it would be painful to implement every single vcs protocol out
> there.
My point is that a URL of the form ‘http://’; would be common, for
repositories that are available publicly only via file-level HTTP, but
uscan would not know from the URL which VCS tool to use.
In other words, encoding the information about which VCS tool to use
is incompatible with my request to preserve the URL for use as-is
outside ‘uscan’.
> Could you please give some detailed/real life examples? Remember
> that uscan looks for latest upstream versions, it may not
> necessarily find a version that has been packaged.
That's exactly what I began talking about: I want uscan to gain the
capability to retrieve a specific, identified working tree state from
the VCS repository.
--
\ “Instead of having ‘answers’ on a math test, they should just |
`\ call them ‘impressions’, and if you got a different |
_o__) ‘impression’, so what, can't we all be brothers?” —Jack Handey |
Ben Finney
Reply to: