Re: meeting notes 20070905

[Tim Moore <timoore@redhat.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Elena Zannoni wrote:

> Impact on the history before the switch: it is maintained. No loss of
> info there doing the import. 
> 
> Import into git from cvs preserved branches. Tim hasn't ported the
> history though. Git got confused at some branch merge points in the
> history. Tim corrected by hand. Since the first import there were no
> more conflicts. Tim does imports/resyncs twice a day, never seen
> further problems. Mark observed some problems also when he did import
> imnto Hg.
> 

This isn't quite right. I did import all the history into my mirror. I have had
to make some after-the-fact fix-ups on a few occasions to get my git repository
back in sync with the CVS tree, but I think this can be attributed in part to the
abusive way in which I'm doing the mirroring. I use parsecvs to construct a new
git repo from scratch when I update the mirror; it's somewhat miraculous (to me :)
that the second repo, in which I've put the symbolic links and other fixes, continues
to work after this. There are certainly better ways to do CVS mirroring, but I stuck
with the program that worked for me and haven't had the bandwidth to search for a
better way. In any event, the mirroring of a CVS tree isn't relevant to a discussion
about which system to change to.

Last night I did an experiment using parsecvs to do the import, then changing the CVS
modules file in order to check out the "raw" directories in our tree. The *only*
differences I found between the CVS checkout and the git checkout were in libunwind
which I knew was a problem because of its origins on the vendor branch. So, I think
we can be confident that an import will preserve our history. It may be best to
put our external dependencies in a different "sub repository," but in any event I'm
confident that we can preserve the history of the libunwind / elfutils commits too.

> Tim kept 2 repos, one using symbolic links. Mark had to do the same
> stuff in Hg.  Frysk-common is the module that presented problems.

I encountered an interesting problem with my symbolic link commit that makes the
source tree look like what the build system expects. One nice feature of git is
"git bisect," which allows you to do a binary search of the history, with checkouts,
to find the point in time when a bug was introduced. If the tree is not buildable
without a later patch, this process becomes awkward... you can do the same machinations
by hand and apply the symbolic links patch at each step, but that's a pain. So, it
may be worthwhile to rewrite history to introduce the symbolic links -- or other fixup --
early in time.

> 
> Expertize in house with each system? Oracle has a few git projects
> already and no Hg. How about Rht?
Jeff Garzik is the author of Kernel Hackers' Guide to git
http://linux.yyz.us/git-howto.html

Tim
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFG4P/peDhWHdXrDRURAhg4AKDacpUnGrWOZzTPTDg46b3l+jQCDACgkTDN
tueU+/O1NQYOpZjRUyQjOfs=
=fkHh
-----END PGP SIGNATURE-----