Gregoire Welraeds wrote:
>
>>> Thanks for your answers. Nevertheless, I'm not looking for yet
>>> another bug tracker which can interact with subversion by post-commit
>>> hooks.
>>> I'm looking for subversion hosted bug tracker. That is why I
>>> mentioned DITrack and subissue in my previous post.
>>> I have the feeling that this 2 projects are stalled.
>> Why do you want to use a tool for something it doesn't do well?
> For a few reasons, among others:
> - Change Requests/issues are tightly related to the code source. IMO,
> they could even be part of the code, like comments and documentation
> are. Change request could be stored directly in Subversion repository,
> next to the source.
I sort-of disagree. Change requests are almost by definition, not what
any version of the code is - and often not even related to anything that
exists. They are generally made by people who don't work directly with
the code, don't have the subversion tools, and want a form/database type
of interaction. That is, they want to count instances of completed and
unfinished requests or find a keyword, not look at yesterday's or last
week's list of requests or compare two lists.
> - It could enforce teams to work with an issues tracker. To some extend,
> Subversion commits comments are just an extension of a Change Request
> description.
I suppose that's remotely possible, but there's not necessarily a
connection. And if you have any formal testing process, it should be
part of the QA process that decides if a request has been completed, not
the fact that some code has been committed.
> - Subversion is very good at manipulating text files and their
> modifications. Why should I use something else?
Because people want searches, lists, and counts in the request and bug
trackers, something subversion isn't good at. And there are free tools
that are good at it.
> - There should be no need to setup additional infrastructure for basic
> needs of issue tracking. Why should I be using a third party software
> for something which is part of my code, especially if it is bundled with
> a third party database.
Because you can. For free. And it will do the job it is designed to do.
> - It would let me work while being offline. Once online: svn update . /
> svn commit . to import my modifications to the issue tracker.
Some trackers have ways to tie the commit revision to the request/bug,
which is all you need.
> - a tight integration of an issue tracker in subversion would let us
> benefits from the inherent features of the VCS and stronger the
> interaction between the two. For instance, I could branch my Change
> Request tree while creating a feature branch in the code.
If the coders get to change the requests to match the code, why bother?
> I could easily
> filter the changes requests by branches, be it maintenance, development,
> feature branches without having to artificially created the same in an
> external third tool.
What would that mean for someone trying to track and verify the feature
deployment/bug fix? What if it isn't all related to code in one
repository?
> As a release manager with a team of 10 developers using Seapine
> TestTrack Pro*, I always end up to look at svn logs to document the
> release. These are only thoughts but I'm sure there are other advantages
> of having both VCS and Issue tracker integrated. BTW, the idea is not
> mine: see subissue, DITrack or even Fossil scm.
Do any of those handle searching/counting/list generation operations
very well? Do they have somewhere to store comments about things that
don't exist yet that can subsequently be tied to a location/revision
when it does? What about related issues that aren't stored in the
repository but still need to be tracked/searched/listed?
--
Les Mikesell
lesmikesell_at_gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1712178
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-04-14 17:33:26 CEST