Re: Improvements to ‘debian/watch’ for fetching from VCS
Ben Finney wrote:
> Raphael Geissert <atomo64+debian@gmail.com> writes:
>
>> Ben Finney wrote:
>> > * the fact that the URL doesn't necessarily indicate what VCS tool is
>> > needed to interact with it (just about all of them allow an HTTP URL
>> > for public read-only access, so that's what will commonly be used
>> > here)
>>
>> That can easily solved, svn+http://...
>
> 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?
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.
>
>> > * the plethora of different concepts for mapping identifiers to
>> > specific working trees in different VCSen (revision-id and branches
>> > and tags, oh my!)
>>
>> uscan would retrieve the information (say the output of svn info
>> svn://domain.tld/repo/) and match the rest of the pattern against the
>> output. Whataver is specified is what would uscan would svn export.
>
> No, I'm referring to the fact that one wants to specify not just the
> repository location, but all the information necessary to identify a
> specific working tree state from the repository. Which might be a
> particular revision committed, or a branch or a tag or whatever.
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.
> Those
> have different syntax, and different semantics, in the different
> VCSes, IIUC.
>
Sure, but support for each vcs would be independent from each other and may
not all be added, at the same time or ever.
Cheers,
Raphael Geissert
Reply to: