[AstroPy] proposal for astropy version control software and respository

[Matthew Turk]

Hi all,

For what it is worth, enzo and yt are both astrophysics projects and
both use and love mercurial; the buy-in feels to be much lower than
that of git, it's much more straightforward, and extensions are very,
very easy to write.  The primary hg hosting solution, BitBucket, has
substantially improved pull requests and other collaborative features
recently, and this has I believe brought it in line with GitHub in
many ways.

One point I feel very strongly about is that under no circumstances
should a scientific code make a habit of 'rewriting history' or
changing the hash numbers of existing revisions.  This would, for
instance, be part of a rebase-based workflow with git or on github.
hg discourages rewriting history, but it seems quite prevalent with
git.  So even if git/github is chosen as a platform, I sincerely hope
that a workflow that does not change existing revision numbers in any
published repository is selected.

Best,

Matt

On Mon, Jul 18, 2011 at 12:08 PM, Christopher De Vries
<chris.h.devries at gmail.com> wrote:
> I think the argument regarding revision numbers is a bit of a red
> herring. In client/server version control a single master repository
> was the rule and checkins were supposed to be well vetted by the
> person authorized to use the server. Distributed version control means
> that people will be working in their own repositories on various bits,
> creating new hashes regularly, which may or may not be uploaded back
> to the github repository in some particular order, so the hashes in
> git and revision numbers in subversion or cvs serve different
> purposes.
>
> Anyway, what I wanted to point out, for mercurial lovers like me, is
> that there is a git plugin for mercurial ( http://hg-git.github.com/ )
> which allows mercurial users to participate in the git ecosystem. I
> have used it for checkouts, though I also find that using git is
> fairly straightforward too. I do not, however, believe there is a good
> plugin for git users to use mercurial repositories, so that would be
> another point in favor of git and github.
>
> Chris
>
> On Mon, Jul 18, 2011 at 11:59 AM, Erik Tollerud <erik.tollerud at gmail.com> wrote:
>>> Yes, subversion has revision numbers are sequential.  They are also
>>> small integers.  You can easily read/write/speak the revision numbers.
>>> You can easily include them in a note, and recognize them when you read
>>> them in another note.
>>>
>>> Git hashes have none of these features.  They are 160 bit opaque data
>>> items.  A computer can test them for equality, but it is not practical
>>> for a human to do that routinely.  You would not write a git hash on a
>>> sticky note.
>>
>> Well, in git you can use only the first 4 characters of a hash and it
>> will work the way a revision number does - that's something you *can*
>> write on a sticky note.  Occasionally its ambiguous if multiple
>> commits have the same first 4 chars, but that's pretty uncommon.
>>
>>
>>> So, git must contain some feature to compensate for this weakness.  For
>>> example, if git has real tags (which subversion does not), you could tag
>>> a version when you need to talk about it.  You might even make a
>>> convention for tag names that are reserved for that kind of use.  It
>>> wouldn't be quite as convenient as revision numbers, but it would come
>>> close.
>>>
>>> Or maybe there is some non-obvious way of using git where you don't miss
>>> having the subversion revision numbers.  I don't know.
>>
>> I'm not sure what you mean by "real" tags in subversion.  Git has tags
>> that are as simple as "git tag <tagname>" (the current commit - in git
>> parlance, HEAD) or "git tag <tagname> <commit-hash>" (tag some other
>> commit).  These can be local to you or you can push them up to the
>> repository.  Tags can also be "lightweight", or annotated - the latter
>> is actually a commit object and thus can have associated messages and
>> be signed and the like.
>>
>> Generally the convention is to use tags locally as shorthand for some
>> commit you often go back to, and publically tag version numbers.  Then
>> the "git describe" command basically gives you all the information you
>> need.
>>
>>
>>> All I'm asking for is a commitment that somebody will spell out the
>>> details after git is selected.  I've had that in off-list discussions,
>>> but I wanted make the case publicly.
>>
>> I would guess we all agree on this, although I'd say it is not really
>> even a git-specific point (although you're right that it is somewhat
>> *more* important in a DVCS due to the flexibility).  If this isn't
>> done to your satisfaction once we actually have the repository up and
>> running, hopefully it can then be corrected, as there will then be
>> something specific to work on.
>>
>>
>>
>> --
>> Erik Tollerud
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> http://mail.scipy.org/mailman/listinfo/astropy
>>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>