[GLLUG] Subversion & Bug Tracking Panel

[Caleb Cushing]

why subvesion vs cvs (obvious) and git (less obvious).

On 3/1/07, frank.dolinar at comcast.net <frank.dolinar at comcast.net> wrote:
>
> Hi, everyone,
>     I know just enough about the Subversion software to think it might be a
> valuable tool.  As yet I have not had the chance to do more than read about
> it and have not used it.
>    I'd like to see it in action and learn something about how it's used.
>    I'm also interested in learning about installation and configuration
> options.
>    A presentation on Subversion would certainly get my interest.
>
> Frank
>
> -------------- Original message --------------
> From: Ed Thomson <ethomson at edwardthomson.com>
>
> > Hi Clay-
> >
> > I've been meaning to introduce myself to the mailing list for a while
> > now, but work's been ridiculously busy lately. I've been to a few
> > GLLUG meetings since I moved up here, so I've met some of you. You
> > probably know me as the evil Mac user, but I still use Linux at home
> > and on all my servers, so hopefully that makes me at least a bit less
> > evil.
> >
> > Anyway, my day job happens to be writing source control software, so
> > you've sparked my interest.
> >
> >
> > So what's cool to me about the version control / bug tracking markets
> > right now is that they're becoming increasingly focused on
> > integration and cohesiveness. The emphasis is really on ALM software
> & gt; - or whatever buzzword the marketing guys want to attach to that -
> > and it would be really interesting to see how free software can
> > tackle some of this integration.
> >
> > That is to say that if subversion could be really well coupled with a
> > bug tracking system and a continuous integration system, that would
> > be a cool presentation. In fact, this is my favorite trade show and
> > presentation demo. What I normally do is something like this:
> >
> > Make a random change to some file in the source tree that would cause
> > a compile error. Check in this change, and marking a bug as fixed in
> > this revision of the tree. At this point, our continuous integration
> > system (in our case, CruiseControl) kicks off a new build. Once the
> > build fails, that bug that was associated with the bad checkin is
> > reopened with a note that the build failed and with the build log
> > attached. < BR>&gt ;
> > It's admittedly a contrived example, but it's something most people
> > can identify with as most of us have worked with That Guy who refuses
> > to actually test his code (or sometimes even compile it) before
> > checking it in. Reaction to this demo ranges from delighted shock to
> > a head nod and a smile, mostly depending on how awful the version
> > control tools they're using are.
> >
> >
> > This sort of integration happens less with the open source issue
> > trackers. SubIssue looks like it will provide a nice integration
> > between bugs and checkins, but it also looks like it might never get
> > out of the gate.
> >
> > But I think that you could at least increase the integration with svn
> > and a random bug tracker a bit. I suspect you could write some svn
> > commit hooks that would examine the comment and look for some well-
> > defined tag that instructs your commit hook to upd ate a bug
> > appropriately. That way I can say something like "> state:resolved>" in
> the comment to mark bug 1454 as resolved as of
> > this new revision of the source tree. It would then mark the bug as
> > resolved, and maybe update the comment that it was modified as of
> > revision 1454.
> >
> > (Ideally, the bug tracking system could also create links to a
> > repository browser for that revision.)
> >
> > To continue the integration, your continuous integration software
> > could, when builds or tests fail, go search for all bugs marked as
> > fixed in the changeset that it just checked out and mark them as
> > resolution denied or reopen them or whatever.
> >
> >
> > Don't know if I'm way off-base or not. Maybe this seems like an
> > arbitrary thing to be so excited about - and it might be. (If so, I
> > apologize, and would suggest that I'm suffering from a sor t of < BR>>
> programmer's Stockholm Syndrome, where I've fallen in love with these
> > things because I'm bound to them.)
> >
> > Cheers-
> >
> > -Ed
> >
> > --
> > Ed Thomson
> >
> > On Mar 1, 2007, at 2:18 PM, Clay Dowling wrote:
> >
> > > I'm one of the presenters for a panel on subversion and bug
> > > tracking at
> > > Penguicon. It occurs to me that I don't necessarily know what
> > > people are
> > > interested in learning about the subject. So let me put it to the
> > > group
> > > here: What would you like to learn about the use of subversion and
> > > bug
> > > tracking? The other presenter has some material about the use of
> > > these
> > > tools as part of a Continuous Integration process. Is there anything
> > > about the Continuous Integration development process that you'd
> > > li ke to
> > > know about?
> > >
> > > Clay
> > > --
> > > Simple Content Management
> > > http://www.ceamus.com
> > >
> > > _______________________________________________
> > > linux-user mailing list
> > > linux-user at egr.msu.edu
> > > http://mailman.egr.msu.edu/mailman/listinfo/linux-user
> >
> > _______________________________________________
> > linux-user mailing list
> > linux-user at egr.msu.edu
> > http://mailman.egr.msu.edu/mailman/listinfo/linux-user
> _______________________________________________
> linux-user mailing list
> linux-user at egr.msu.edu
> http://mailman.egr.msu.edu/mailman/listinfo/linux-user
>
>