Re: Subversion tagging

> In an ideal world...sure.

> In the real world you'll commit this changeset believing that yes,
> it contains all that's required for this particular fix. But then
> QA gets ahold of it and woops, it didn't pass. So you revisit the
> fix, complete the part you missed, and commit it. The process
> repeats, but now your nice tidy atomic commit is spread across two
> revisions. By the time it actually gets through QA, user acceptance,
> and legal, it may actually include dozens of revisions...

> What would you do instead? Roll back your changes each time and
> try again from scratch so that when it finally passes it would be
> in a single tidy revision?

For what it's worth, we have a ticketing system which is used to track what changes were applied for what fix. This existed long before we switched to Subversion. So a ticket is raised which encapsulates a bug fix or enhancement request. There's development, and the ticket gets updated with which revisions were created with the changes.

The ticket gets tested, and lets say it fails a test (theoretically :) ). The tester documents in the ticket the reasons for failure. More development ensues, we don't start from scratch, just record more in the ticket what subsequent changes were made. Rinse, lather repeat.

We at no time expect that all changes for a single ticket are required to be represented by a single Subversion Repository revision. We have plenty of changes which are just too large for that. Even for simple one-file changes, we will have multiple revisions where that fix may be merge into various releases we have to support.

The ticket also tracks where the changes were applied (trunk and/or branches). As part of our process, we have a web application which extracts the changed files for a ticket (across all of the revisions defined for the ticket) so we can code review changes (using ViewVC for diffs, or also load the diffs into other file compare utilities).

With something like this, we don't expect the version control repository to keep track of all this information: it's not its job.

With iterative development, tickets are simply created for each tasks defined as part of each iteration. So, the final look of new functionality may span across multiple tickets (where the functionality was refined with each pass of the iterative wheel - a lot of times, waterfall processes don't fully define the requirement set).

So, I'd argue that the scenario you're describing isn't best satisfied by demanding file-level tags in Subversion. But I can only speak about the processes I've been exposed to as well as what I find works for us. We have a ticketing system we can use, I don't know if you have one there which is available. There are some open source systems if cost is an issue (IssueZilla), but I wouldn't expect any versioning system to be able to contain all the information I need to track for any chance we do for our software for standards accrediations.

Send instant messages to your online friends http://au.messenger.yahoo.com

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Jan 23 02:57:12 2007