Hi Dscho &amp; everyone,<div><br></div><div>Thanks, and good point about large commits. For the most part we can adhere to &quot;commit early, commit often,&quot; although certain kinds of changes (mass source file relocation, for example) look ugly in the history no matter what you do.</div>

<div><br></div><div>Anyway, as mentioned in another thread, I have migrated the ImageJDev ImageJ repository over to SVN. I also set up Git on the new dev server, and imglib is still using git, so keeping our imglib repositories synced will hopefully continue to be straightforward.</div>

<div><br></div><div>As for syncing ImageJ, I&#39;m sure our SVN will diverge from both ImageJ and ImageJA—intentionally so as we refactor various things—so for the time being we would need to backport changes, improvements and bugfixes as they happen. When we all meet at the October conference, we can discuss the best longterm strategy to reconcile the various code branches.</div>

<div><br></div><div>Regards,</div><div>Curtis<br><br><div class="gmail_quote">On Thu, Sep 2, 2010 at 2:21 AM, Johannes Schindelin <span dir="ltr">&lt;<a href="mailto:Johannes.Schindelin@gmx.de">Johannes.Schindelin@gmx.de</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hi,<br>
<div class="im"><br>
On Wed, 1 Sep 2010, Curtis Rueden wrote:<br>
<br>
&gt; In conclusion, I am frankly frustrated with Git, and feel SVN would be<br>
&gt; an easier choice for both our own development team as well as the larger<br>
&gt; ImageJ community.<br>
<br>
</div>If you&#39;re frustrated with Git, then it is certainly advisable to switch<br>
away from it. An SCM should help you develop things, not distract from it.<br>
<div class="im"><br>
&gt; However, I welcome discussion, as there are certainly downsides to<br>
&gt; switching away from Git.<br>
<br>
</div>Not so many as you think: inclined developers can always use git-svn.<br>
<br>
However, you should make sure to uphold the discipline _not_ to commit<br>
huge chunks of unreviewably large changes.<br>
<br>
This is the curse of Subversion: it is hard to polish patch series until<br>
they shine. The dear consequence is often that you get a commit history<br>
that is unreviewable. And what is unreviewable is not reviewed properly.<br>
<br>
For example, I would _positively_ hate it if I saw a single monster commit<br>
adding the abstract plugin infrastructure. Remember: there are patches so<br>
small and sweet that there are no obvious programming mistakes. And there<br>
are patches so clunky and heavy and ugly that there are no obvious<br>
programming mistakes.<br>
<br>
Ciao,<br>
Dscho<br>
<br>
</blockquote></div><br></div>