Hola,
I think the problem is we are using the same words with a different
criteria. So let me clarify with a real example.
Below is a link to a real Apache's tracker issue: DERBY-4857
https://issues.apache.org/jira/browse/DERBY-4857?page=com.atlassian.jira.plugin.ext.subversion%3Asubversion-commits-tabpanel
You are speaking about the "Affects Version/s:" field defined at the top of
the page with has the value: 10.7.11 and it corresponds with this tag:
http://svn.apache.org/repos/asf/db/derby/code/tags/10.7.1.1
created at the revision number: 1.049.172
I understand you when you say that there is a revision (release) before the
issue, therefore an issue can always be related with a revision/release/tag
On the other hand, I'm speaking about the "Subversion commits" panel/tab at
the bottom of the same page. When a developer commits a revision then he
must type the issue key in the comment in order to relate both.
In this case the issue DERBY-4857 is related with this revisions: 1027056,
1027878, 1027882, 1030383 and 1030471.
Relationships between issues and releases/tags are well supported by
Subversion because the concept "Release" in a tracker can be directly
related with a tag in Subversion. Depending of your needs, tracking
revisions only at the "release" level may be enough. But for big products
with a long life and with many developer working at the same time on them
might be very useful also relate Subversion revisions with a more detailed
concepts (issues). These last sort of relationships are not well supported
by Subversion, so all the job is done at the tracker side (the Jira
Subversion plugin in this case). Concepts like bug, task, requirement cannot
directly be related with any Subversion concept.
Thus, I think that a flexible concept like "label" able to be related with
revisions would improve Subversion as SCCM tool.
Regarding my exact words mentioned in your mail, I think they are a bit
confusing. But the meaning should be what I've just explained above.
On Thu, Jan 13, 2011 at 3:07 PM, Ignacio G. T. <
igtorque.remove_at_evomer.yahoo.es> wrote:
> Hola, Pablo.
>
> El 20:59, Pablo Beltran escribió:
> >
>
> [...]
>
>
> That is mainly because many things happens BEFORE Subversion revisions
>> are created. For example, when a bug is detected there is not a
>> revision to be related until the bug is fixed in Subversion.
>>
>
> [...]
>
> I'm afraid I don't understand you.
>
> When we release software, we can identify it with a version name, which we
> link to a specific subdirectory in the "version" directory of the
> repository, which is, in turn, related to a unique svn revision number.
>
> All the bugs that our clients report (very few :-) are traced to a specific
> version, so there is a unique svn revision number related to that bug. Of
> course, the bug may have contaminated other versions until it was detected,
> but there IS at least a number although the bug is not fixed yet.
>
Received on 2011-01-13 18:03:57 CET