[AstroPy] proposal for astropy version control software and respository
Christopher De Vries
chris.h.devries at gmail.com
Mon Jul 18 15:08:44 EDT 2011
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
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.
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
>> 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
>> 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
More information about the AstroPy