[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Improvements to ‘debian/watch’ for fetching from VCS

Ben Finney wrote:
Noah Slater <nslater@tumbolia.org> writes:

On Fri, Apr 03, 2009 at 10:04:21AM +1100, Ben Finney wrote:
* the plethora of different concepts for mapping identifiers to
  specific working trees in different VCSen (revision-id and branches
  and tags, oh my!)
This could be possible with a set of configurable rules, akin to make.

      svn co http://example.org/ $DIR

      svn co -r $REV http://example.org/ $DIR

As long as you standardised the variables passed, and the location,
should work.

That's the trouble though. AIUI, different VCSen have different ways
of identifying a specific state of the working tree; we have not only
revisions, but also tags, branches, threads, heads, and probably
others I've forgotten. Should all of those be allowed? Is that too
complex an interface?

What is $REV? How user know about a specific $REV? So I think
we need to parse the $REV, which we or upstream insert in changelog,
bug reports etc.  If user want more detailed use of $REV, it
should use the underlying VCS. I doubt that project use multiple
way to describe a revision.

[BTW: we should allow debian version (epoch and debian revision optional)
to $REV. Looking ad the version and/or changelog, the script should
attempt to find the mapper $REV, but without doing too hard.

As for “latest”: is there an unambiguous “latest” for every
repository? What does this mean with repositories that have
simultaneous lines of history within the same location?

latest stable? latest devel in a tree (python 2.x)? or
latest devel (sid like)?
It depends on package. A library with SONAME encoded in
package name has different need that a normal package

I think we should provide an helper, not the definitive
tool. So maintainer should have some control, and
user should expect that tools don't provide (or provide
a "old" source).


Reply to: