There are some convincing arguments, but IMHO, this is (at least for
the time being) beyond the scope of a version control system.
The way I look at it, DITrack is what you are looking for, but is
lacking a huge set of core features that most other OTS issue tracking
systems already have. It is a start, but it's not like it's
integrated into SVN, you need to have both svn and DITrack installed
to take advantage of the DITrack db in the repo. I see DITrack as
feeling out how to solve a problem the svn developers may (or may not)
consider in the future - somewhat like SVK of a few years ago, which
now some of the functionality/solutions that svk provided are now
being included as part of the core functionality of svn. However, the
difference is that SVK is also a VCS. If there was a desire to have
such functionality of DITrack, I feel it would be better to solve this
through the method that issue 2917 would resolve. In this fashion the
core functionality of subversion would be to provide version control
and periphery projects implemented through lua could be "dropped" into
to a subversion repository extending the core functionality.
See:
http://subversion.ti?gris.org/issues/show?_bug.cgi?id=2917
Quoting Gregoire Welraeds <gregoire.welraeds_at_side-international.com>:
> On 14/04/2009 14:33, Les Mikesell wrote:
>> 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.
> - 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.
> - Subversion is very good at manipulating text files and their
> modifications. Why should I use something else?
> - 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.
> - It would let me work while being offline. Once online: svn update . /
> svn commit . to import my modifications to the issue tracker.
> - 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. 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.
>
> 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.
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1710959
>
> To unsubscribe from this discussion, e-mail:
> [users-unsubscribe_at_subversion.tigris.org].
>
Received on 2009-04-14 16:13:48 CEST