On 11 Aug 2008, at 05:38, Manuel M T Chakravarty wrote:
Correct me if I am wrong, but this sounds as if you support my point that switching the GHC repo to git without doing the same for the core libs (in an integrated way) would not address the problems you experienced with darcs.
Partly. It does address some issues (fear of conflict, speed, case- sensitivity bugs, easier branches). I personally wouldn't mind having both Darcs and Git repositories, although I can understand why having a mixture of both is bad. I was just mentioning some other advantages of also having the libraries in Git. However, I think that it would be really disappointing if we would not move to Git for the main GHC repository. Simon M reported that a merge took him over a whole day, Norman reported two weeks of lost work, Don reported corrupted repos, Simon PJ reported that in order to avoid conflicts he constantly unrecords and re-records one big patch; all that doesn't give much confidence in Darcs. Additionally, no-one except David seems to actually understand Darcs' theory (and we don't even know if David actually does.) Darcs 2 claims to fix those problems, but I don't know how many are actually using it. Darcs 1 had the exponential runtime bug and it wasn't discovered right away. I don't believe that Darcs 2 can fulfil GHC's needs anytime soon, especially since it is always a bad idea to use a brand-new release of a not much used VCS. (I am also no longer convinced that Darcs' automatic patch dependency calculations are actually a good idea. Just because two patches don't touch the same files, doesn't mean they aren't semantically dependent. Take for example "monadification" patches, which are typically submitted split up for each file. A branch captures those dependencies just fine.) / Thomas -- Push the envelope. Watch it bend.