PROPOSAL: Subversion as an Issue Tracker?

[Peter Davis <pe...@pdavis.cx>]

Maybe I'm crazy, but I'm starting a new project of my own, and I thought, 
"Hey, I don't want to spend the effort to set up Bugzilla, I don't have the 
money to spend on IssueZilla (as nice as it looks), and I don't have a Tomcat 
server available to run Scarab.  Why not put my issues in the obvious place, 
with the rest of my source?"

Stop reading this right now if you think I'm insane.  Mostly I'm just thinking 
aloud here, but I'm also soliciting comments on (1) why this is or could be 
doomed to fail from the start, or (2) um, just comments.  If a significant 
number of people don't think I'm insane, then I might just start developing 
this as its own project, for use outside my own project.

What I'm envisioning consists of some scripts and maybe a web interface, and 
an addition to the somewhat standard subversion tree, called "issue/" (note 
that out of my own convention, I don't pluralize the directory names, but 
adapt as you will; names would be configurable):

repos/
  trunk/
  branch/
    issue/
      [issue-names]/
    release/
      [release-names]/
  tag/
    milestone/
    release/
  issue/
    assigned/
      [commiters'-usernames]/
         [issue-names]/
    new/
      [issue-names]/
    resolved/
      [issue-names]/

Each issue gets its own directory within either new/, assigned/[username]/, or 
resolved/, and that directory gets "svn mv"ed around as its status changes. 
If svn supported symbolic links right now, I'd want to also have a directory 
called "all/", where all the "real" issue directories would be stored, and 
then the ones in assigned/, new/, and resolved/ would just be links.  The 
issues' names would likely be prefixed by (or consist only of) a number, just 
like each issue in other trackers gets its own unique ID.  Naming conventions 
would ensure that two people don't commit two issues with the same number at 
the same time, since that would cause a conflict.

Within each issue directory, the original issue is stored as a file called 
"issue".  This is a plain text file, and it functions similar to the way in 
which, say, Debian's bug tracking works over email.  It consists of headers 
in "Header-Name: Contents" form, followed by the description of the issue.  
The headers are obvious, like "Summary:", "Author:", "Date:", "Platform:", 
"Component:", etc.  Also contained in this file are headers like "Status:", 
which are modified when necessary.

Each new comment to the issue gets stored as "comment-XXX", where people can 
post comments with similar headers.

And of course people could post attachments as regular files, maybe in an 
"attachments/" subdirectory.


Do you think I'm crazy yet?  Obviously this is heavily reliant on people 
following some seemingly arbitrary naming conventions.  If I develop this 
further, most of that development will go towards making a set of 
cross-platform scripts (Python?) to do the dirty work of creating the files 
and ensuring validity, possibly as a post-commit script to do the management.  
Alternatively, if it's ever possible to run PHP scripts straight out of a 
mod_dav_svn repository, then it could get really interesting... :)  I could 
write a web interface that itself is part of the repository, maybe treated 
like a vendor branch.

As you can see, my goal is to have all my issues, tools, source, ...everything 
all self-contained in a single repository.  Subversion, with its nice 
directory support, lends itself to this goal.  Also, it would allow easy 
editing of issues with *any* editor (not just a web browser, which I think is 
one reason why existing issue trackers don't appeal to me) with full history.

Immediate advantages:
* Text based: edit/create with any editor, search with "grep -r"
* Automatically organizing: the most common reporting can be done with "svn 
ls" (see who is working on what, check up on new issues, see what has been 
resolved).
* Automatically benefits from commit-email.pl
* Full history tracking: Subversion records the date and author of all 
additions, and you can even edit existing issues to correct typos.

Issues with my issues:
* What would be expected of log messages to issue commits?  Writing a log 
message in addition to writing an issue description would get tedious.
* Before a web or other interface is created, creating new issues will be 
especially tedious.  A template system could alleviate some of this.
* [your comments here]

Todo before it's really viable:
* Use PHP, Perl, or Python with SWIG svn bindings to write a web interface.
* Along those lines, it should be possible to run PHP/CGI in Apache straight 
from a repository (maybe it is already, I haven't tried).
* Figure out a way to easily and efficiently index all of the issues.
* Subversion needs to support symbolic links.  This would simplify 
organizational issues, and also would enable logical dependency tracking by 
creating links directly from one issue to another (in a dependency/ 
subdirectory, maybe).  Modules (svn:externals) could substitute in the mean 
time, but modifying svn:externals would be tedious and unmaintainable.


Does everyone still think I'm crazy?  I guess it doesn't matter, since anyone 
reading this is obviously crazy and has too much free time.  Let me know what 
you think; is such a project worth further thought?  Was this incredibly long 
email worth your time? :)

DISCLAIMER: Of course I would never want to distract from Collabnet's 
SourceCast/IssueZilla, from which I understand much of the support for 
Subversion comes, or from the other issue trackers hosted by Tigris.org :)

-- 
Peter Davis

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: PROPOSAL: Subversion as an Issue Tracker?

[Peter Davis <pe...@pdavis.cx>]

On Thursday 01 August 2002 09:45, you wrote:
> The project sounds really interesting!  You should maybe set up a new
> tigris.org project for it?  (If the tigris.org domain managers are
> okay with that; see the web pages for more on that.)

Cool.  I will probably try do that in the next few days.

> But beyond that, let's please take it off the Subversion dev list.
> This is a project using Subversion as a base, not a project extending
> Subversion itself (which is how it differs from, say, RapidSVN).  When
> the project turns up bugs or missing features in Subversion, then post
> here of course.  But the project itself is distinct from Subversion,
> and for obvious reasons we can't have traffic on the SVN dev list for
> every project which happens to *use* Subversion as a base :-).
>
> (The initial announcement post is fine, nothing wrong with that.  I'm
> just saying let's not make a thread of it.)

Don't worry, I wasn't planning on it.  I just wanted to see peoples' 
reactions.  If/when the time comes, the project will definitely have its own 
list.

Thanks for your support!  I may be posting some feature requests, or at least 
bugging you guys a little :->.  I also might have some Apache/Subversion 
integration questions, and definitely some questions about how to use SWIG 
bindings (I haven't used SWIG before).  But I will definitely try and limit 
the dev@subversion traffic to stuff that is on-topic, and of course I'll read 
the HACKING docs before anything else (I'll go and start doing that right 
now).  Thanks again!

-- 
Peter Davis

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: PROPOSAL: Subversion as an Issue Tracker?

[Karl Fogel <kf...@newton.ch.collab.net>]

Peter Davis <pe...@pdavis.cx> writes:
> DISCLAIMER: Of course I would never want to distract from Collabnet's 
> SourceCast/IssueZilla, from which I understand much of the support for 
> Subversion comes, or from the other issue trackers hosted by Tigris.org :)

The project sounds really interesting!  You should maybe set up a new
tigris.org project for it?  (If the tigris.org domain managers are
okay with that; see the web pages for more on that.)

But beyond that, let's please take it off the Subversion dev list.
This is a project using Subversion as a base, not a project extending
Subversion itself (which is how it differs from, say, RapidSVN).  When
the project turns up bugs or missing features in Subversion, then post
here of course.  But the project itself is distinct from Subversion,
and for obvious reasons we can't have traffic on the SVN dev list for
every project which happens to *use* Subversion as a base :-).

(The initial announcement post is fine, nothing wrong with that.  I'm
just saying let's not make a thread of it.)

-K

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: PROPOSAL: Subversion as an Issue Tracker?

["Sergey A. Lipnevich" <se...@pisem.net>]

Hi,

Before I read to the end of it. I was planning on using XML output with 
smart XSL which would detect series like <bug id=x>fixed</bug> or 
whatever in the log messages and create a link (<a/>) to Bugzilla, so 
that while browsing sources you could see log messages with links.  The 
backwards integration with Bugzilla is also possible if (big if) 
mod_dav_svn supported browsing of previous revisions and specific 
requests like "show me files that have changed in revision X". This way, 
it would be possible to put special tags in issue comments which would 
link to SVN. It's not more than idea now, but given some time ;-)... 
What do you think?
Thanks,

Sergey.

Peter Davis wrote:

>Maybe I'm crazy, but I'm starting a new project of my own, and I thought, 
>"Hey, I don't want to spend the effort to set up Bugzilla, I don't have the 
>money to spend on IssueZilla (as nice as it looks), and I don't have a Tomcat 
>server available to run Scarab.  Why not put my issues in the obvious place, 
>with the rest of my source?"
>
>skipped
>



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org