meeting notes 20070905

meeting notes 20070905

[Elena Zannoni]

[-- Attachment #1: Type: text/plain, Size: 1 bytes --]



[-- Attachment #2: frysk-20070905 --]
[-- Type: text/plain, Size: 2544 bytes --]

Frysk meeting 2007-09-05

Version control systems discussions

Tim Andrew Elena Stan Mark Sami [who else?]

Do people that prefer strongly one system have played around with the
others as well?

Tim --> likes Git, hasn't tried Hg
Mark --> Hg

See comparisons posted to mailing list by Mark.


overseers of sourceware.org, what's their take? Would anybody among
them be willing to administer the git/hg stuff. Is there somebody
knowledge there to use as point of reference.

Mark: would stay with cvs, because it's the evil we know. Need to have
somebody to know well how to do the day to day stuff with Hg or Git.
Imports, commits, setting up emails, cutting branches, etc. Mark
hasn't worked enough with any of them to know which system is
safer. He doesn't know well either of them.  How to translate the
current procedures for imports and branches into the new git or hg
framework. 

freedesktop has a split repositories. Developers have personal
repositories where they post their stuff/wip so that it's accessible
to everyone.

having a better scs would allow to have a deamon working through the
head of trunk testing each changeset. as they get committed.

notification: hot to check what's going in? frysk-cvs works well now.
Do those systems have the same stuff? Potential to include the patch
in the email, instead of the link. 

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.

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.

Plugins: cvs plugin in eclipse. No other plugins for eclipse.
cvs module in emacs as well. no emacs modes for git and Hg.


Advantage over cvs is that one can recover easily from erroneous
commits, because of the changesets.


What projects we know of are using Git and which ones are using Hg?

Git: kernel, libunwind
Hg: icedtea, openjdk, mozilla


There will be a new page in the website listing pros/cons of the two
systems. People need to fill it in.
http://sourceware.org/frysk/vc/

Expertize in house with each system? Oracle has a few git projects
already and no Hg. How about Rht?


No meeting next week. 

Re: meeting notes 20070905

[Phil Muldoon]

Elena Zannoni wrote:

Some further notes. Minutes as an attachment make in-line comments 
painful :(

> Frysk meeting 2007-09-05
>
> Version control systems discussions
>
> Tim Andrew Elena Stan Mark Sami [who else?]
>

Phil

> Do people that prefer strongly one system have played around with the
> others as well?
>
> Tim --> likes Git, hasn't tried Hg
> Mark --> Hg

Phil --> either, as long as it is not CVS. We have decades of combined 
CVS experience, yet there are still mistakes made daily. Some of which 
take hours and hours to recover from. At some point have to look at the 
tool, and not the developer and perhaps think that a newer, better one 
is needed. Personally (further down) there are lots of projects moving 
to DCM. Including OpenJDK, Mozilla, Kernel, ASLA, Xen, RPM, etc etc to 
name a few. I find the "stay with CVS as it is known" a bit of a false 
argument. Borked and old != better.

> Plugins: cvs plugin in eclipse. No other plugins for eclipse.
> cvs module in emacs as well. no emacs modes for git and Hg.

Incorrect at least for Mercurial:

http://www.selenic.com/mercurial/wiki/index.cgi/OtherTools

No idea about GiT though I am sure Tim will fill in.

> Advantage over cvs is that one can recover easily from erroneous
> commits, because of the changesets.

Active developer community, saner interface (goodbye to positional 
switches!). Trac and Maven integration.

> What projects we know of are using Git and which ones are using Hg?
>
> Git: kernel, libunwind
> Hg: icedtea, openjdk, mozilla
For Mercurial

http://www.selenic.com/mercurial/wiki/index.cgi/ProjectsUsingMercurial

I'll fill all this data into the webpage, too.

Regards

Phil

Re: meeting notes 20070905

[Tim Moore]

-----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-----