Re: [OT] interested in subversion-friendly project management SW

Nick_Gianakas@sybari.com wrote:
> I think practically every issue tracker has this capability. Branches
> worth keeping track of are typically releases. If configured, the issue
> tracker supports one or more releases for a particular issue. So branch X
> is probably version 1.X, which could have an entry in the issue tracker.

Yes. And no.

I can fiddle with the tool and manually decide that it applies to
releases X, Y and Z.

Now it gets fixed, verified and closed in release X. (But is still
unfixed in Y and Z). At least in the tools I know of, I can not get it
to show that it originally applied to releases X, Y and Z, but is fixed
in X only. The tools I've seen only support listing which releases the
current bug state applies to, so history is lost.

Also, assume the fix is in rev. 4000 on branch REL_X.

Now a merge like:

svn merge -r 3900:4100 $repos/branches/REL_X .

is done and comitted in a REL_Y working copy.

Therefore, this bug got fixed in branch Y, and needs verification on
branch Y. This bugfix should be automatically detected!!! Why should a
human have to do that? Sure, it needs verification: "Does the merged
functionality actually work on the new branch?" But that goes for all
merge modifications. The bug should automatically get marked as fixed
but not verified on branch Y.

Now, the bug is Fixed, verified and closed on branch X, fixed but not
verified on branch Y and unfixed on branch Z.

What tool can track this real-life behavior? And why aren't others
wanting this, I wonder most of all...

Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Jan 18 17:38:38 2005