discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: git mirror


From: David Chisnall
Subject: Re: git mirror
Date: Wed, 15 Feb 2012 15:04:26 +0000

On 15 Feb 2012, at 13:06, Quentin Mathé wrote:

> I fully agree with having Git or Hg as the master rather than SVN.

There are two issues that I'd like to see a good solution for with this:

The first is that we lose a monotonic counter for revisions.  If someone has a 
bug, with svn you can say 'I think this is fixed in r12345, are you running an 
older revision than this?' and they can actually answer it.  With git, you say 
'I think this is fixed in 4f13bc56' and they say 'well, I'm running 5196f8a' 
and you say 'I have no idea what the relationship between the two is, one of us 
needs to go and look at the timeline and see, and it's not going to be me 
because you're the one with the problem' and they say 'fine, I don't care 
either, your project sucks'.

The other issue is that git does not support partial checkouts.  This means 
that we would have to split the GNUstep repository up into a load of sub 
projects.  I don't see this as a major issue for things like Gorm, which are 
largely independent, but I have in the past wanted to make changes to libobjc2 
and base, or base and gui, or gui and back where the change in one layer 
requires corresponding changes in another.  With svn, even though I have 
checked all of these projects out separately, I can do an atomic commit to the 
entire project so we never have an inconsistent state in the authoritative 
repository - people either see the state before the commit or after.  With git 
(and, I believe, all of the other DVCSs that have been suggested) this is not 
possible, so someone can do a checkout of the core GNUstep modules and find 
them in a non-building state.

This is not a problem in the common case, but it is if you find that someone 
has introduced a conflict in between the two commits (which has happened to me 
in the past too).  If, for example, Fred makes some changes in -gui while I am 
about to commit something to -base and -gui so that my -gui changes now need 
manual merging, then with svn the entire base-and-gui changeset fails to apply. 
 I then do the merging and commit.  With git, I can push the base changes, but 
then I'll have to merge the gui changes.  During this time, base-and-gui in the 
public repository is in an inconsistent unbuildable state.  

I'm not opposed to switching to a DVCS in principle, but I do want to make sure 
that we're not going to introduce regressions in the way that we work simply to 
be buzzword compliant.

David

P.S. One of my other pet peeves about git is that it asks for confirmation on 
commit (which is something that you can undo), but not on push (which you 
can't), which leads to lots of faffing trying to undo things in a repository 
that you may not have control over.

--
This email complies with ISO 3103


reply via email to

[Prev in Thread] Current Thread [Next in Thread]