Version control systems

Manuel M T Chakravarty chak at cse.unsw.edu.au
Sun Aug 10 05:06:58 EDT 2008


Jason Dagit:
> 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.
>
> People will be working on making darcs work better with the GHC repo  
> as a test case either way.  And personally, since I'm not a GHC dev,  
> the decision doesn't affect my life.  Having said that, I'm still  
> obviously biased.  I'd love for darcs to work well enough that this  
> never came up.

Same here, and fwiw I won't change any of my many other darcs repos  
any time soon.

However, as I have said before, if ghc is to switch, it must be a  
clean switch, and no messy use of two vcs at the same time for ghc and  
boot libs.

> 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?

I don't think that this technical feasible.  I used tailor once to  
convert a CVS repo to darcs, and while that was better than throwing  
away the history, it was pretty messy and nothing that you would want  
to do on a regular basis.  Besides, even if the actual conversion  
would work smoothly (which I strongly doubt), you'd immediately be  
faced with problems of atomicity and associated race conditions of  
commits to the two repos.

Manuel



More information about the Glasgow-haskell-users mailing list