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. get-recent: svn co http://example.org/ $DIR get-revision: 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). ciao cate