[Cialug] Version Control

[Ken MacLeod]

On 6/7/07, David Bierce <operations at cynicbytrade.com> wrote:
> Ello --
>
> Last night I watched Linus give his google talk on version control.
> Has anyone played around with GIT?  Or used GIT with Subversion?

I've used Git with CVS, SVN, and ClearCase.  Git's standalone
repository, raw speed, and features complement any VCS.  It's
particularly good at "slurping in" different versions of the same
project sources from different places and making sense of them.

Some Git+<other-vcs> uses:

 *  Export <vcs> history to Git to merge histories with upstream,
Linux distributions, and others.  For example, if you maintain a
kernel tree (in patches, RPMs, or expanded in your own <vcs>), you can
see kernel.org's, Red Hat's, and your own kernels in a common history.

 *  Use Git and <vcs> in parallel.  Check out your <vcs> workarea,
"git initdb; git commit".  You can use Git for snapshotting, importing
and working with patches using Git's merge algorithms, and my
favorite, using "Stacked Git" (stgit, a Git-based version of Quilt) to
manage a set of related patches to send to an upstream project.  (A
tip/warning on snapshotting: your <vcs> is your primary <vcs>, Git is
an in-between convenience -- commit into your <vcs> early and often.)

 *  Use Git to perform a complicated, no-history merge: you should
already be using the "vendor branch" practice or design pattern.
Create a workarea on your vendor branch and make a copy of it.  Run
"git initdb; git commit" on the copy, create and switch to a Git
branch.  Remove the file contents of your workarea (except the .git
directory) and unpack/untar your new software release.  Have Git
import the new code into the branch, deleting removed files and adding
new files.  Commit into the Git branch.  Merge the Git branch back
into master and switch back to master.  View the commit diff (eg.
gitk) to find file renames.  Back in your <vcs> workarea, rename the
files in your <vcs>, then copy the Git workarea into the <vcs>
workarea.  Add new files in your <vcs>.  Commit all changed files.  At
this point your <vcs> vendor branch should have all changes from the
new software release.  Tag/label your <vcs> vendor branch.  Create a
new development branch from your old development branch for basing off
of the new vendor release.  Merge the new vendor release into your new
development branch.  Since you've created a clean merge in the vendor
branch history your <vcs> (except CVS) should rather easily handle the
merge from the new vendor baseline to your new development branch.
With CVS or if a test run with your <vcs> shows excessive merge
conflicts, use the same Git technique to merge your vendor branch to
your development branch and make sure to "merge" once more to record
the merge history.  If you think this sounds complicated, try it
without Git :-).

 *  Use gitweb in addition to or in place of your <vcs> online
browser.  gitweb has a cleaner interface than some others but the real
win is that Git can easily import from many repositories.  If you're
working with open source, you can have one single "read-only gitweb
Git repository" for all of your projects, regardless of VCS of choice,
and share history with all upstream projects, all in one place.  To
make imports easier, keep each one separate and rebuildable, and then
use Git's clone-by-linking and grafting to give the appearance of a
single common history.


SVN Tip: SVN will make use of merge history if you tell it the
revision you last merged with, ie. "merge changes from <other-branch>
from <last-merged-revision> to <current-revision> into
<current-branch>".  Google "svn merge revision number" for specifics.
svnmerge.py can automate that until SVN catches up.