>DVCS talk is heating up again.

>So with the latest round of “Murphy’s Law” intruding in on some routine server upgrades at eclipse, the talk of needing to have a DVCS available started heating up again. Currently it seems that there are two view points:

  • We do not need it
  • It’s the greatest thing since sliced bread.

While researching DVCS and the various options I ran across an interesting blog post, “Let’s talk about DVCS”. The main body of the blog is alright, the really interesting bits come down in the comments section. One interesting comment comes from the GNOME Do [1] project:

In the development of Gnome Do we loved using bzr. If someone wanted to come in and try to implement a feature we just said “go for it, create a branch”. We could then follow it, test it, make suggestions. We didn’t have to setup extra accounts or create a branch for this person to use ourselves. Because merging is so much easier to do in bzr, once the guy got the branch in shape, it was not problem to merge it into one of our branches and get it into release. — Rick Harding

CVS and Subversion really make merging a pain. Also working with Branches is no fun in CVS, SVN is a bit better here. The big advantage though is allowing a user to have a basic local copy of the tree, work on their changes in whatever way they want, and then submitting a patch. Right now a contributor has to maintain multiple versions of a patch as changes are made to the base line during development. If you have extensive changes that need to be done as you’ve done some pretty extensive refactorings it can become a real pain to manage these.

There are reasons to allow DVCS, but I also think it should work with existing repositories and not necessarily replace them. I also think that it might be time for CVS to see it’s end of life at eclipse. Subversion truelly is a step up, and there are bridges that allow various DVCS systems to work with Subversion and keep in synch. The issue for subversion migration at the least is the issue of redistribution of the SVNKit libraries since they aren’t licensed under an approved license.

Regardless though, DVCS is something that should be considered where it makes sense. Anything that we can do to help make it easier for potential contributors and committers to work on eclipse code, should be done. It’s a win-win for both groups.

[1] Updated: Corrected the reference to the Gnome Do project instead of the Gnome project.

Advertisements
This entry was posted in dvcs, eclipse, release engineering. Bookmark the permalink.

9 Responses to >DVCS talk is heating up again.

  1. Eric Rizzo says:

    >IMO, for Eclipse to move to SVN as the primary vcs, the SVN tooling would have to be *at least* as complete and usable as the CVS integration currently is. Last time I looked, neither Subversive nor Subclipse could honestly make that claim.Has that changed to the point where us users would not miss anything?

  2. David Carver says:

    >I use Subclipse daily, and it works just fine. As for getting it to that point, a sure way to get it there is to start mandating that SVN be used. That is how CVS got to where it is. It was the only option so the tooling had to be created.

  3. David says:

    >The comment about GNOME Do is from the GNOME Do project, which is not the same as the GNOME project.David (maintainer of GNOME Do)

  4. David Carver says:

    >@David: Thanks for the correction. I’ve made the correction in the entry and provided a link back to the project.

  5. Kim Moir says:

    >In order for CVS to see its EOL @ eclipse, there needs to be a migration path to a new repository that retains history. My understanding is that if a project requests moving a to SVN for example, the history isn’t retained. This is a problem for older projects because need to be able to create patches and reproduce older builds in maintenance streams. The other issue in addition to support in the IDE is support in the build space…does the technology that a project uses to fetch, generate build scripts etc. for the bundles support the new repo type? Finally, moving to a new repo is a large migration exercise that needs extensive planning and testing to ensure that it’s successful with little downtime for developers. There needs to be very compelling reasons to migrate to a new repo to offset the opportunity cost of planning the migration versus fixing other bugs 🙂

  6. David Carver says:

    >@Kim, there is cvs2svn, that will migrate all history and revisions to the new SVN repository. I’ve used it to migrate multiple cvs repositories to svn and it works quite well.The build issue can be addressed as well. You already have eclipse projects building from SVN repositories. Many of the issues have been addressed either by eclipse projects themselves, or by external tools. There are multiple ways to build eclipse projects…see some of my prior blog postings about this.We can always find reasons to NOT do something. However, I think the benefit in the long run of modernizing the tooling and repository options out weighs the short term pain.

  7. Kim Moir says:

    >I’m not opposed to moving to new repos and using new tooling. I’m certainly aware there’s more than one way to build eclipse. My point is that by taking the time to move to a new repo and iron out all the wrinkles in the build scripts means deferring other bugs. Thus there must be very compelling reasons to upgrade given limited resources.

  8. David Carver says:

    >Agreed…but i would argue that one builds that migration into existing work load and planning processes. Also the build script should seperate the checkout process from the actual build process. Unfortunately, I do not think some eclipse builds are done this way, thus it’s more work for some than others.The problem I see with the build is that certain legacy assumptions makes it more painful to do a repository migration than it actually has to be.

  9. Abel Muiño says:

    >I'm intrigued by the fact that DVCS make merging easier and that would simplify getting new features from contributors.For that to happen, the IP process should first be changed to allow merging those fetures (currently, only patches of <500 lines are allowed without providing a zip for review).To me (being only an amateur using git) it seems that DVCS only provide local history and easier forking (this might be very interesting for companies willing to build their products).

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s