Version control systems

Brandon S. Allbery KF8NH allbery at ece.cmu.edu
Sun Aug 10 02:47:57 EDT 2008


On 2008 Aug 10, at 2:12, Jason Dagit wrote:
> On Sat, Aug 9, 2008 at 10:44 PM, Roman Leshchinskiy <rl at cse.unsw.edu.au 
> > wrote:
>
> Maybe investing some time in fixing the most obvious darcs problems  
> would be a better solution?
>
> We're working on that over at Darcs HQ, but there is no guarantee  
> that we'd come close to fixing the problems within the 4-5 week  
> window that Ian mentioned.  Supposing that the main problems GHC has  
> with darcs 2 format get solved in the next month, would that give  
> GHC reason enough to keep using darcs?  It seems many of you are  
> eager to use git; perhaps even if darcs was working to satisfaction.

Some people are.  I'm more on the side of "are we creating a bigger  
problem than we already have?"  It's not at all clear to me that  
switching to git would solve more problems than it would cause --- and  
if you toss in core libraries possibly needing to stay in darcs, or  
other projects being abruptly forced to switch to git because the core  
libs did, it's pretty clearly on the "biting off more than we can  
chew" side of things.

> Let me throw out one more idea:
> What if, as a GHC contributor, I could pick equally between git and  
> darcs?  My understanding is that, while not optimal, you could use  
> tailor[1] to synchronize a darcs repository with a git one.  Offer  
> up both repositories and keep them in sync.  Let the masses decide?


There has been some discussion along those lines, but doing that  
bidirectionally is logitically difficult.

-- 
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery at kf8nh.com
system administrator [openafs,heimdal,too many hats] allbery at ece.cmu.edu
electrical and computer engineering, carnegie mellon university    KF8NH


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080810/e0707a3b/attachment.htm


More information about the Glasgow-haskell-users mailing list