Version control systems

[Ian Lynagh]

On Mon, Aug 11, 2008 at 04:17:59PM +0100, Simon Marlow wrote:
> 
> One way we could create the forks would be to create a git repo for each 
> package with two branches: the master branch that GHC builds, and a 
> separate branch that tracks the main darcs repository, and is synced 
> automatically whenever patches are pushed to the main darcs repo.  We'd 
> have to explicitly merge the tracking branch into the master branch from 
> time to time.  When we want to make changes locally, we can just commit 
> them to the GHC branch and push the changes upstream in a batch later (and 
> then we'd end up having to merge them back in to the GHC branch... but 
> hopefully git's merge is clever enough to avoid manual intervention here). 
>  This is complicated and ugly of course; better suggestions welcome.

I don't think that this will work well. At some point we'll have to
resolve conflicts that accumulate (by rebasing GHC-only patches after
conflicting upstream patches come in? This may not be trivial, as the
rebaser may not be familiar with the patches), and I suspect that the
forks will end up diverging for significant periods of time, as there's
little impetus to merge them.

Even the current situation with Cabal is a bit of a pain, as it's easy
to forget to push patches upstream as well as GHC's repo, and that's
just with 2 repos of the same VCS.

I actually think the original plan, where only the ghc repo (plus one or
two others) is in git is preferable. You may have to use a different VCS
for different subprojects, but after that it's downhill all the way.
You don't have to worry about patches being converted from one VCS to
another, moved to another repo, converted back and merged back into the
first repo.

I expect people will be using different VCSs for different /projects/,
if not subprojects, anyway.


Thanks
Ian