Raphael Geissert <atomo64+deb...@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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org