On Sat 2004-04-03 at 22:39:52 +0200, Florian Weimer wrote:
[...]
> In CVS, you see that the defect was introduced in release 1.131, and was
> fixed in release 1.157. With good repository maintainance, you can look
> at the tags in that interval to compile a list of releases and/or
> branches that contain the offending code.
You mean like this?
$ svn log -r1131:2157 -q -v http://svn.collab.net/repos/svn/tags
------------------------------------------------------------------------
r1320 | kfogel | 2002-02-19 21:50:54 +0100 (Tue, 19 Feb 2002)
Changed paths:
A /tags/0.9 (from /trunk:1302)
------------------------------------------------------------------------
r1321 | kfogel | 2002-02-19 21:51:40 +0100 (Tue, 19 Feb 2002)
Changed paths:
A /tags/0.8 (from /tags/0.8.0:1320)
D /tags/0.8.0
[...]
Or in a more compact form:
$ svn log -r1131:2157 -q -v $REP/tags | grep "A .tags"
A /tags/0.9 (from /trunk:1302)
A /tags/0.8 (from /tags/0.8.0:1320)
A /tags/0.10.0 (from /trunk:1467)
A /tags/0.10.0/trunk (from /trunk:1467)
A /tags/0.10.1 (from /trunk:1537)
A /tags/0.10.2 (from /trunk:1587)
(with "export REP=http://svn.collab.net/repos/svn")
Note that this misses tags that were created _from_ a revision in
between r1131:2157 but actually _made_ after 2157, but if you do make
the lookup after you fixed the bug, there is no revision after the
bug-fix 2157, so no new tags. In other words: Usually not a big
problem.
To fix this flaw, one can use a little script-fu. With me being best
at awk, I would write it that way:
$ svn log -q -v $REP/tags | awk -F: '/A .tags/ && $2>=1131 && $2<=2157'
A /tags/0.13.0 (from /trunk:2140)
A /tags/0.12.0 (from /trunk:1868)
A /tags/0.11.1 (from /trunk:1682)
A /tags/0.10.2 (from /trunk:1587)
A /tags/0.10.1 (from /trunk:1537)
A /tags/0.10 (from /trunk:1467)
A /tags/0.10.2 (from /trunk:1587)
A /tags/0.10.1 (from /trunk:1537)
A /tags/0.10.0/trunk (from /trunk:1467)
A /tags/0.10.0 (from /trunk:1467)
A /tags/0.8 (from /tags/0.8.0:1320)
A /tags/0.9 (from /trunk:1302)
(note that this has much more tags and even some duplicates, because
someone (re-)creates tags in bulk around r2600)
It is easier to just use svn ls (but it looses information about
deleted tags, which may be good or bad depending on your needs):
$ svn ls -v -r2157 $REP/tags
1321 kfogel Feb 19 2002 0.8/
1320 kfogel Feb 19 2002 0.9/
(the 0.10.x tags were deleted at that point in time, so although this
looks buggy, it's more a result of how tags were handled... you would
have the same problem with deleted tags in CVS)
So, while the direct ways to query tags may show more info than
needed, the output is flexible enough to be massaged into any of the
usually needed reports.
Bye,
Benjamin.
PS: And there may be better ways to archieve the same, the above just
is what I came up with off-hand.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Apr 5 20:10:50 2004