On Wed, 15 Nov 2006, Dmitri Colebatch wrote:
> On 11/15/06, Nikki Locke <firstname.lastname@example.org> wrote:
> > Tim Hill wrote:
> > > The main issue, as I see it, is that many
> > > svn workflows involve operations between different revisions in a
> > > repository, but that there is no real syntax for accessing those
> > > revisions symbolically.
> > Can you give some examples of such operations?
> > I'm relatively new to Subversion, and I'm having trouble understanding
> > exactly what you would want to do that can't be done with tags.
> We've recently migrated from cvs to svn and the single biggest thing I'm
> struggling with is the following scenario:
> I get a bug report from the field, or I want to pre-emptively check to see
> if a particular fix made it into a release (releases might be in QA for
> weeks before going out to production). In cvs, I would know that the tag in
> QA/production is "tag_20061115a". Using IntelliJ I would then view history
> of that file and I can scan down the history to see which version has that
I'm working with a similar setup - perhaps this can help.
Short answer: We drop the bug number in the subversion checkin log (as
opposed to a label), then search for it through 'svn log' or trac - don't
worry, it's not as painful as it sounds.
Our bug-tracking system that's completely unhooked from svn, so the
documentation about what-commit-fixes-what-bug are basically manual.
That documentation is in the form of a checkin comment - there's a
pre-commit hook that 'helps' the developer with the format of the
first line of the checkin comment- it ends up looking like
BUG #1234 - Fixed the hoojiwhatsit on the thingamajig
multi-line comments as needed
From there, it's a straightforward search through svn's logs to track
down the revision that had the bugfix. Conversely, I've recently started
using trac as a repository browser, and its Search feature will search
through checkin comments. Granted, we've only got a repository with <1500
commits, but it's darned speedy.
As a side note, I'm using svnmerge.py to deal with merging from
stabilization branches to trunk. svnmerge's generated comment for the
merge checkin slurps in all the comments for the checkins being merged
(including the bug number), so searching for a particular bug number in
trac gets you both the branch(es) / revisions of the original set of checkins,
plus everywhere they were merged. Goodness.
svn + svnmerge + trac is turning out to be a great combination. But, it
all goes back to your core point - that of documentation. If you don't
get that bug number associated with that revision, you're sunk.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Wed Nov 15 14:49:01 2006