Re: LANDIS-II project infrastructure - version control
James Domingo
> The L-II project infrastructure also includes a few Google Code projects.
> We're assessing which of these would be most appropriate to add LIME to.
To which Norman Danner replied:
> Are the projects using Hg for version control? It looks like Google
> Code supports SVN and Hg, and so we're assuming we'll use Hg.
Because version control is a software engineering best practice, we set it
up when work started on LANDIS-II in 2004. At that time, Subversion (svn)
was a mature version control system (VCS). Distributed VCSes like Git and
Mercurial (Hg) were not available yet (they started in 2005).
Our svn repositories were initially hosted at the University of Wisconsin
because access needed to be restricted. Like other research software,
LANDIS-II's long term goal was to become an open-source project. But in
the initial stage, access was limited until the initial research with
LANDIS-II was published. At that point, the source code was opened. A
major benefit of that is we could migrate to a free svn provider (like
Google or Sourceforge), which freed up resources that were allocated to
managing a local svn setup.
Because of this history, all the LANDIS-II projects at Google Code use
svn. If LIME is added to one of those, then obviously it'll use svn. But
Rob and I discussed the option of a new Google Code project where LIME
might reside. In that case, the new project could use Hg.
Selection of a VCS is a significant infrastructure decision. Given that
the current LANDIS-II projects use svn, there's a strong argument for a
new Google Code project to use svn. But distributed VCSes (like Hg) have
emerged to address the limitations of centralized VCSes (like svn). I
haven't used a distributed VCS (D-VCS), but I've noticed more and more
open-sourceprojects are using them.
Are D-VCSes being emphasized to undergrads in the HFOSS project? Do the
interns and you have prior experience with Hg?
Jimm
--
James Domingo
Green Code LLC
Norman Danner
On 6/2/11 11:40 AM, James Domingo wrote:
> Because of this history, all the LANDIS-II projects at Google Code use
> svn. If LIME is added to one of those, then obviously it'll use svn. But
> Rob and I discussed the option of a new Google Code project where LIME
> might reside. In that case, the new project could use Hg.
>
> Selection of a VCS is a significant infrastructure decision. Given that
> the current LANDIS-II projects use svn, there's a strong argument for a
> new Google Code project to use svn. But distributed VCSes (like Hg) have
> emerged to address the limitations of centralized VCSes (like svn). I
> haven't used a distributed VCS (D-VCS), but I've noticed more and more
> open-sourceprojects are using them.
>
> Are D-VCSes being emphasized to undergrads in the HFOSS project? Do the
> interns and you have prior experience with Hg?
I certainly understand that the history would push toward svn. As you
guessed, we are emphasizing DVCSes in the HFOSS Project, as they are
quite mature now and an awful lot of major open-source projects use a
DVCS. My impression is that all new big projects use a DVCS. I also
think it is probably easier to transfer working knowledge of something
like Hg to SVN if needed.
Although we don't have a lot of experience with Hg, I have a lot with
bzr and a reasonable amount with Git---browsing the Hg docs, I don't
think it will be a challenge to pick it up. And I'm sure that Hg
supports a centralized workflow that lets individual developers treat it
just like one uses svn repositories. Certainly Git and bzr do, in a way
that still allows developers to take advantage of the benefits of a
DVCS. The basic model is that we set up a repository R on Google Code;
developers clone it to their own local machines; developers do almost
all work locally; whenever a significant chunk of work is done,
developer pushes it back up to R.
I think making LIME into its own Google Code project is a good idea
because as I see it right now, LIME is really a client of L-II. And by
starting a smaller project like LIME in Hg, this could perhaps give L-II
developers a chance to cut their teeth on DVCSes on a smaller project,
with probably less severe consequences for mistakes (just because the
project is much younger, so no mistakes can be *that* serious).
Having said all of that, we will work with what you want done---to be
honest, you will probably have to live with the decision for longer than
we will. If you want us to use svn, we will use svn.
Please let us know what you think.
- Norman
--
Norman Danner - nda...@wesleyan.edu - http://ndanner.web.wesleyan.edu
Department of Mathematics and Computer Science - Wesleyan University
James Domingo
Thanks for the information about the maturity and growing use of DVCSes
as well as for your personal experience with them. It's encouraging
that they can support a centralized workflow similar to a CVCS (like
svn). That can help with the transition from CVCS to DVCS.
Plus, the idea of using LIME as a pilot project to introduce a DVCS
(Hg) to the L-II developer community is a very good idea.
These points together make a compelling argument for setting up LIME as
a new project using Hg. I'll do that today or tomorrow and then send
out word that it's ready.
Jimm
--
James Domingo
Green Code LLC