[En-Nut-Discussion] Moving to Subversion

[Thiago A. Corrêa]

Hi,

   Just my opinion on this, please don't take anything personaly.

On Fri, Feb 27, 2009 at 2:05 PM, Marti Raudsepp <marti at juffo.org> wrote:
> May I suggest considering distributed version control systems before
> making that decision? Lots of open source projects are already
> migrating from Subversion to distributed systems; as far as I can tell
> it's only a matter of time when SVN meets the same fate as CVS.

Subversion is actively developed, recently they improved their merging
algorithms.
Different projects have different requirements, just because others
are using something else, it doesn't mean we should.
Also, we host our code, bugtracker, etc at SourceForge. Anything
different than CVS or SVN would be considering moving the hosting of
the code at least.

There is also another concern: The revision history. SVN has ways of
converting the CVS repository without loosing the history.

> If you're not yet familiar with distributed VCSes, here are main advantages:
> * Branching and merging is much very natural because it's the normal
> mode of operation. Every time you clone, you get a new branch. Every
> time you want to get the changes from a diverging repository, you
> merge.

On the other hand, normal operation is different from what we are used
to. I for one was never able to understand git, and I'm not going to
try either.

> * Revisions can be commited by anyone and later merged into the main
> repository by trusted users: The version control system is useful for
> those without commit access.

I use buildroot with my own copy of the repository (vendor branches)
and I do svn merge from the upstream tree directly into my working
copy.
So, nothing new.

> * In general, DVCSes put less constraints on workflows. You can use
> them like a centralized systems, but you won't want to, once you get
> to understand them.

We might have something between 3 to 5 active developers right now,
and I'm including myself, even though I commit just every now and
then. I don't see how that would benefit us. On the other hand moving
from CVS to subversion gives us atomic commits, so we can see from svn
log what changed in all files. That alone is an advantage. Granted,
every modern version control system does that, but at least svn makes
sense to us considering what we have always used up to now.

> * Maintaining, publishing and merging back experimental or third-party
> repositories is much easier. This is especially useful for maintaining
> private changes on top of the official Nut/OS source tree.

Vendor branches is one possibility, see my buildroot example above.

> * Even if written in Python, distributed systems are usually
> significantly faster than Subversion. :)

I've used Subversion for ages, and performance of subversion itself
have never seem to bother me. We spend far more time wainting for gcc
to do it's job every day than subversion or CVS for that matter.

> * No central point of failure.

Sourceforge manages that for us for free.

> * Offline operation. You can make multiple commits locally before
> pushing them up to the public server.

That might be nice.

> * (At least in Mercurial), changesets can be e-mailed around like
> patches, but they retain their metadata (commiter name, commit time
> and base revision) and always apply cleanly.

We don't have nearly the same requirements as the Linux Kernel on that
matter. We have few patches submited.
Sure it would be very nice if we could get more ppl to get involved,
but I don't think the vcs is what will attract them our way, whatever
may it be.

> These advantages may not seem significant at first in face of SVN's
> popularity, but they enable lots of flexibility. Many OSS projects
> have considered the switch worthwhile. For more information, Linus's
> Google Talk about git touches all the aspects of why distribution
> matters: http://www.youtube.com/watch?v=4XpnKHJAok8
>

Mozilla and many others had also ruled them out publicly. Until
recently Git's win32 support was praticaly unexistant. And from what I
could find, it's still a bit awkward. Depending on cygwin isn't
properly supporting Win32, just like providing win32 binaries to run
under Wine isn't properly supporting Linux.

We should consider what are our requirements and make up our mind for
ourselfs, not based on other project's decisions.


Kind Regards,
   Thiago A. Correa