[AstroPy] proposal for astropy version control software and respository

[Mark Sienkiewicz]

>>
>> But it would sure suck to lose the revision numbers that subversion has
>> (but git does not) and not get something pretty intensely useful in
>> return.  I hope you git guys know what that is.
>
> I'm not sure what you mean here. Revision numbers in what sense? Git 
> does track versions by numbers (if very large ones...). Do you mean 
> numbers that have some sequential properties or something like that?

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.

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.


> Secondly, yes, there are lots of different possible workflows that one 
> could use with git, and one could, in principle, make a mess of 
> things. But the fact is that a lot of projects are using git very 
> nicely. If it often caused an unholy mess, I don't think they are such 
> religious zealots that they would overlook that aspect. They generally 
> are making it work one way or another.

I think it does not cause an unholy mess when everybody involved is a 
true believer.  The failure mode I want to avoid is where git-advocates 
have no trouble working with the system, but the git-inexperienced 
cannot use it effectively.


> So no, I don't think all the details need to be spelled out ahead of 
> time before a poll is taken. Those details can be worked out if there 
> appears to a sizable majority willing to go that way.

Yes, that is one approach.  You are asking for people to accept an 
as-yet-unselected choice from a class of possible work flows.  I'm 
confident that at least one of them can be made to work, so I agree that 
the details do not need to be spelled out in advance.

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.

Mark