0

got a new lenny installation now, we are a small team of 3 devs working on a already old and getting bigger project. We deploy the program every now and then to new client (like once a month), with new features. So we need to get a little more organized, i had installed trac some time ago on my debian etch server, however it installed the 0.10.3, and a bunch of things never worked right. Now these days we realized we really need the system. So i tried to upgrade and well, everything went to hell cause i messed up here and there.

thing is, i got a new lenny debian, but i wanted to ask you guys, if you recommend a different tracking system, or do you think trac would do the trick ? only requisite is that it´s easy to install and uninstall with apt-get. i really liked that you could browse the svn, however, the console admin did not like that much.

Thank you!

3 Answers 3

1

I've used trac+svn on my last job as well as on my current job. I gotta say I find the setup to be awesome! The way you can cross-reference tickets (in trac) and revisions (in svn) is very compelling. When being close to deployment I like to tie every commit very tightly to a ticket, making it easy to keep track of the changes even on larger dev teams.

Setting it up on debian should be easy using apt-get install.

An alternative to trac is Mantis. I haven't used Mantis nearly as much as I've used Trac, but I certainly didn't like it as much.


EDIT: To setup svn/trac references you need to do two things as far as I remember:

  1. Setup a post-commit hook on your svn repository.
  2. Edit you trac.ini.

I think this is quite well explained here, event though the text could be clearer.

This is from my setup:

  1. Setting up a post-commit hook on your svn repository. The following is from my /path/to/svn/repos/myrepo/hooks/post-commit :

    REPOS="$1"
    REV="$2"
    
    TRAC_ENV="/path/to/trac/"
    /usr/bin/python /usr/share/doc/packages/trac/contrib/trac-post-commit-hook -p "$TRAC_ENV" -r "$REV"
    
  2. Edit you trac.ini. This is what I have added to my ini file, I don't remember the details around them, so you'll need to look that up yourself:

    [trac]
    ....
    repository_dir = /path/to/svn/repos/myrepo/
    repository_type = svn
    ...
    
    [svn]
    branches = trunk,branches/*
    tags = tags/*
    
    [components]
    trac.versioncontrol.svn_fs.subversionconnector = enabled
    

EDIT 2: What I am referring to with "keeping it tight" is actually not enforced by svn nor trac, its just a mindset that I think work very well, at least in my group. We use trac from the beginning to end of each development cycle, and we put all requested features/bug fixes/enhancement into tickets. As soon a feature has been developed the developer puts the ticket up for testing, and when the testing has been approved (by PL) the ticket is closed. During the normal cycle, however, sometimes developers commits things that are not related to any ticket, it could be a small feature or a bug fix that no-one knew about, and here you get two choices: either you let it go (fast, simple) or you create a new ticket to tie the commit to (slow, cumbersome). We usually go by the quick fix here unless it is a major new feature.

Towards the end of the cycle, however, it gets more and more important to keep track of each commit, as every commit potentially could break the system. Thus I find it very useful to force (by the spoken word) each developer to in each commit write what ticket id the commit is related to. (If you in the comment write #123 as you commit to svn where 123 is the ticket number you can actually browse this in the trac time line, awesome!)

This has two effects: 1) The developers take one extra look before they commit, so that everything in each commit is only related to the specific ticket. 2) It gets easier for me to see what features/bug fixes that I can test per commit. I could for example checkout revision 123 to test one bug fix and 124 to test another, if I would like to test them one at a time.

Well, this starts to become an small essay and I need to stop here. I hope that you understand what I mean. I guess my advice would be to setup your own guidelines that are well-known within the development group, and make use of #123 (ref to ticket) and r234 (ref to svn revision) as you write commit-comments and new tickets.

(I.e., when you reply to a ticket you write "I fixed XYZ in r345.", then r345 will become a link to the svn tree and you can see exactly what was changed in this revision.

5
  • Added url to install guide for debian. Sep 24, 2010 at 21:53
  • Thank you very much for your answer Avada, i got trac installed again and it´s working, i would like to consult you about something, not sure if i should open a new question for it. 1.- Where can i find a guide to make this cross references you talk about, or some tips? because i´m really interested on this feature, i remember i originally picked trac because of it. 2.- Which Plugins can you recommend, i would love a UI for trac administration. Thank you!
    – Ernest
    Sep 27, 2010 at 13:20
  • Added some info regarding trac+svn. I am sorry if its not very clear, its been a while since i set it up myself. I am not using many plugins myself and I have not setup any UI for administration, more than the webbased one that comes with trac, so I am no litte use here. Sep 27, 2010 at 14:13
  • Hello, Avada. Got the info, thankyou very much. I already have the trac+svn, i think i did not asked for what i really needed. Think what i meant is how you keep it all tight together ? like you write commits with a special format ? i refer to the part of your post that states: "When being close to deployment I like to tie every commit very tightly to a ticket, making it easy to keep track of the changes even on larger dev teams."
    – Ernest
    Sep 27, 2010 at 21:10
  • Hello Ernest, I again edited my answer to. I hope you'll find this useful. Sep 28, 2010 at 6:46
1

I don't know much about trac (in fact, I never heard of it). For simple requirements I have had a lot of success with mantis. It's not the most powerful or elegant ticket tracker out there, but it's easy to install and configure and it will do all your basic tricks. Actually, when you dig down a little deeper, it can do a lot of tricks, but (as usual) you have to put some time into configuring it for your purposes.

0

With a recent debian or ubuntu release it is trivial to install redmine, which I like better than trac.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .