[AstroPy] AstroPy Digest, Vol 58, Issue 16

[Erik Tollerud]

> One thing I would bring up is that there have been any number of
> yak-shaving discussions about rebasing and history rewriting and
> dropping things from the reflog after the matplotlib, numpy, cython
> and scipy projects have moved.  Hopefully AstroPy will be able to
> avoid these by allowing or favoring a branchy model of development.
> One thing I have noticed is that these discussions seem to happen much
> more commonly with git than hg, and I'm not entirely clear on why that
> is; I suspect it may just be that hg encourages one not to rewrite
> history, and so the hydra-approach is more accepted.  With Enzo
> specifically branchy development has been very handy.

I whole-heartedly agree with Matthew's sentiment here - branching
development is something that is far better suited to the problem we
face here of trying to connect together rather disparate tools.  As
Perry, Thomas, and Tommy all pointed out in slightly different ways,
the problem in astronomy is more complicated because it will probably
*always* be a bunch of continually evolving pieces that need to be
integrated in changing ways. It's hard to imagine how to sanely manage
this without persistent branches. (And I think git and github do a
somewhat better job of managing branches than hg/bitbucket do,
although that may be mostly a matter of opinion).





> Yes - if the new repository requires a different VCS, then some people
> will have to learn to use the new VCS.  In the case of a DVCS, there is
> a new work flow that you need to explain to potential developers.  For
> example, I could have to support both svn and git for my developers.
>
> On the plus side, numpy is using git.  If you choose git, then I don't
> need _two_ new VCS.
>
> On the minus side, during my last major software build, I did not
> succeed in compiling git on my linux machines.  But then, the last time
> I tried to compile subverion, it didn't work either.  The dependencies
> of both are nasty.

This is an important point, *BUT* there is actually a big difference
between a DVCS and a non-D VCS in ease-of-use over the lifetime of the
project (which we are hoping is very long!).  So the question is more
whether or not it's worth the extra time to get people to learn the
distributed type.  I personally have not found it to be that difficult
to learn both hg and git, and actually I think it's *easier* in many
ways to teach those to people that don't know any sort of VCS at all.
And the advantages of a DVCS in the case of a community-driven project
will pay for the initial extra effort many times over.

>>  By using a distributed versioning system (e.g. git or hg) and a free hosting solution (neutral territory, e.g. github or mercurial) we can ensure that the project will live beyond the funding for any given institution, and the distributed aspect means that if the hosting solution goes out of business, moving to another will be easy.
>
> In fact, a DVCS makes little difference to this case.  You can make your
> own private copy of the astrolib subversion repository at any time.  I
> keep daily backups of all my off-site subversion repositories (astrolib
> is not the only thing I have at Assembla) as part of my disaster
> recovery plan.  I know the backups are valid because my CI system checks
> out code from the backups, so the backups are routinely tested.

Technically true, but more important is the fact that DVCSs inherently
*always* do this whenever you check something out.  This has the added
advantage of allowing any number of local commits and forks and ease
of merging them back in.  That's a big part of why it's great for a
far-flung community like any astronomy library will inevitably be.

And the fact that this is part of the philosophy is why the
distributed code hosting services (github and bitbucket, primarily)
seem to blow most others away in terms of feature sets (for the
developer, at least, if not always the admin) and easy-of-use...
they're designed specifically to suit the needs of a distributed
community.

Then again, I did say earlier that this decision should wait until we
have an agreed-on vision.  I guess what I've been writing is based
mostly on my vision. (and perhaps that's why there seems to be some
disagreement here... or perhaps there's no disagreement... it's a bit
hard to tell :)


-- 
Erik Tollerud