How we keep in sync with CMake's CVS head
E. Wing
>
> Are you all patching the CMake source directly? I would discourage
> this as much as possible. Even when I'm building C++ modules from
> scratch I don't do this.
Yes and no. We are directly making changes to the CMake source. We
would like to refactor to help isolate the Lua bits more, to avoid
potential merge conflicts, but we're working with the source that was
originally done by Dr. Ken Martin.
However our merge strategy is not haphazard. This is where distributed
SCMs come in. Distributed SCMs excel at forking and merging. The idea
is that CMakeLua is a fork of CMake. Using a distributed SCM allows us
to fork off, but but we can continue to pull/merge changes from the
official CMake repo so we can keep up-to-date. The tools do most of
the hard work and we don't have to think too much about it except when
there is a merge conflict. So this goes back to the refactoring idea.
If we can minimize potential merge conflicts, then things get even
easier.
Of the distributed SCMs, Git and Mercurial seem to have the most
mindshare and seem to be the most serious contenders. I picked
Mercurial for the main CMake repo because it has the best
cross-platform support right now. Git on Windows right now won't make
most Windows users happy and Windows is a big/important part of
CMake's base.
Now unfortunately, CMake uses CVS (which is crap) and is totally
ignorant of forking and merging. So we setup an intermediate repo
bridge. Using a project called "Tailor" (known as the 'Rosetta stone
of SCMs'), we can create a bridge between two repositories. So we use
Tailor to create a bridge from the official CVS and convert it into a
Mercurial repo. This bridge repository stays clean of any fork changes
and only keeps official CMake stuff. This bridge repo contains both
the CVS and Mercurial information.
From the bridge, now that there is a Mercurial repo under it, we can
push the changes to a real forked repository. This is the repository
you see at Assembla. We are free to make Lua changes in the Assembla
repository and do what we want.
Then periodically, I will run Tailor on the bridge repo which pulls
from CMake's CVS and update the bridge repo. I push from the bridge
repo and let Mercurial do the merge between the official CMake changes
(CVS) and our Lua fork (Mercurial). Generally, Mercurial then just
does its thing and you're done. If you hit a merge conflict, you need
to resolve them and on OS X, they pull up FileMerge.app and you get to
figure it out. Not fun, but there's not much that can be done about
this. The hope is that this is infrequent.
(By the way, I think O'Sullivan said this is how Stackless Python
operates, but I could be mis-remembering it.)
Ultimately, if we were officially accepted to remerge with CMake, I
believe we could create a patch between the Tailor repo and the
CMakeLua repo which could then be applied to CMake. But I haven't
tested this theory.
Now the one problem thus far has been that I completely own the Tailor
repository as there hasn't been an easy way to share this since it is
an intermediate repository. It can't be checked into CVS or Mercurial
since it has both bits of data which will confuse the process. I
uploaded a snapshot in the Files section at Assembla, but it gets out
of date. Since CVS is not distributed, I don't know how well it will
work with multiple people doing things. But right now, I'm a
bottleneck, so I'm looking to at least try to remove the dependency on
me. So my solution is to put it a Git repository hosted somewhere and
we can designate somebody to do the updates as needed. Details on this
will follow shortly.
Thanks,
Eric