[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Mark Bohlman <mbohlman_at_tcicredit.com>
Date: 2005-01-18 17:56:20 CET

Peter Valdemar Mørch wrote:
> 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
>

Actually, there was a tool written that would, if I recall correctly, do
exactly what you want. But it was designed specifically (originally)
for the Ingres database development effort and to my knowledge has never
been made publicly available anywhere. Which is sad, because those that
used it really liked the power it provided. It tracked changes across
platforms, branches and versions allowing rapid porting of code to the
multitude of environments Ingres was offered on.

-- Mark

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

This is an archived mail posted to the Subversion Users mailing list.