<?xml version="1.0" encoding="utf-8"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title>t+1 - Latest Comments in Ditz versus bugs everywhere</title><link>http://tplus1.disqus.com/</link><description></description><atom:link href="http://tplus1.disqus.com/ditz_versus_bugs_everywhere_27/latest.rss" rel="self"></atom:link><language>en</language><lastBuildDate>Sat, 14 Aug 2010 00:05:49 -0000</lastBuildDate><item><title>Re: Ditz versus bugs everywhere</title><link>http://blog.tplus1.com/index.php/2008/12/22/ditz-versus-bugs-everywhere/#comment-68649433</link><description>&lt;p&gt;Storing them in a seperate branch is  IMHO much more elegant than having a separate directory or a database. Git it's self is already more or less a database under the covers,it uses a key value system much like couchdb. The porcelain is just a wrapper around it.  The main difference is that if your using git, it already exists in your project.&lt;/p&gt;

&lt;p&gt;Note it only stores the issues related things in a separate branch. Nothing else. If you resolve an issue, or create a bug it all gets stored in one branch. When you commit, and resolve the issue/bug it adds the sha1 which is unique in the entire tree accross all branches. So you can not only tell where it is fixed but you can cherry-pick or merge at your leisure. Also, before you say keeping the issues is memory is faster, in theory this is correct. However git is very fast and the (guessing http ) overhead to couch is such that if you actually try this out ( at least for me ) git was marginally quicker.&lt;/p&gt;

&lt;p&gt;The problem you mentioned with it being git-centric still stands.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Andrew M</dc:creator><pubDate>Sat, 14 Aug 2010 00:05:49 -0000</pubDate></item><item><title>Re: Ditz versus bugs everywhere</title><link>http://blog.tplus1.com/index.php/2008/12/22/ditz-versus-bugs-everywhere/#comment-5804773</link><description>&lt;p&gt;thanks,&lt;br&gt;both ditz and git-issues seem interesting tools&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">dalloliogm</dc:creator><pubDate>Tue, 03 Feb 2009 05:35:11 -0000</pubDate></item><item><title>Re: Ditz versus bugs everywhere</title><link>http://blog.tplus1.com/index.php/2008/12/22/ditz-versus-bugs-everywhere/#comment-4703579</link><description>&lt;p&gt;Nope, didn't know about git-issues. Thanks for the link!  It's always&lt;br&gt;good to see how different people tackle problems.&lt;/p&gt;

&lt;p&gt;After reading the README, I have a few half-baked objections:&lt;/p&gt;

&lt;p&gt;1. The issues are stored in a separate branch.  So, as far as I can&lt;br&gt;tell, it wouldn't be obvious if one branch of code has resolved an&lt;br&gt;issue while another branch hasn't.&lt;/p&gt;

&lt;p&gt;2. It's git-centric.  I like git, but I don't like the idea of forcing&lt;br&gt;hard-linking the ticketing system to a particular version control&lt;br&gt;system.&lt;/p&gt;

&lt;p&gt;These aren't deal-breakers, these are just stylistic differences I&lt;br&gt;have with the author.&lt;/p&gt;

&lt;p&gt;Anyhow, thanks again for the link.&lt;/p&gt;

&lt;p&gt;Matt&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Matt Wilson</dc:creator><pubDate>Sun, 28 Dec 2008 19:43:12 -0000</pubDate></item><item><title>Re: Ditz versus bugs everywhere</title><link>http://blog.tplus1.com/index.php/2008/12/22/ditz-versus-bugs-everywhere/#comment-4682458</link><description>&lt;p&gt;Did you have a look at &lt;a href="http://github.com/jwiegley/git-issues/tree/master" rel="nofollow"&gt;http://github.com/jwiegley/git...&lt;/a&gt; ?&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Mikhail Sobolev</dc:creator><pubDate>Sun, 28 Dec 2008 17:00:50 -0000</pubDate></item></channel></rss>
