Les Mikesell <lesmikesell_at_gmail.com> wrote on 04/14/2009 11:28:20 AM:
> 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.
Right - change requests are related to changelists, not source. The
developers tend to want to ask questions like "Tell me what change
requests this changelist was in response to" and the converse "which
changelist(s) fixed this issue".
> Some trackers have ways to tie the commit revision to the request/bug,
> which is all you need.
Yup. But they tend to do it with commit hooks, which some people aren't
comfortable with. I can understand that: to much code in the commit hooks
leads to to likely failures in said code, which
> > 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?
And those queries be answered based on the changelist/request
relationship: I.e. - "find change requests attached to change lists which
affect files on this branch".
Not trying to start a flame war, but I recommend taking a look at how
perforce (which is in many ways similar to svn, a similarity that's
increasing as subversion adds/improves features) handles these things.
They added a "job" class to the backend database, and a few simple tools
for editing/querying that class, plus a way to link them to changelists.
Yes, it's a lousy change request tracking system, because all it really is
is a change request database + some query tools. A variety of third party
tools use that back end jobs database to build real request tracking
systems. On reflection, it might not be applicable to subversion because
perforce allows users (well, admins) to do form database like
configuration for standard objects (users, workspaces, changelists, and
probably others I'm missing), so that jobs were an easy add. I don't think
subversion allows that, so it may not fit so well. But I think it's still
worth looking at.
<mike
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1712853
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-04-14 18:34:04 CEST