Ben Finney wrote:
Noah Slater <nsla...@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
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
