[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Testbed-admins] Emulab source code moving from CVS to git



[Note: You're receiving this mail because you're on one of the Emulab
 development or administrator lists, or have requested access to the
 Emulab CVS repository.]

This is a heads-up regarding a change in the way that the Emulab
source code will be managed and made available to developers.

Within the next couple of weeks, we will be moving the Emulab source
code repository out of the 80s and into the present: we'll be
migrating from CVS to git. git, if you are not familiar with it, is a
decentralized source code management system that was originally
developed for doing source control for the Linux kernel and is now
widely used by a variety of other projects:
    http://www.git-scm.org/

The basic access method will continue to be over ssh, to
git-public.flux.utah.edu . Everyone with an account on 'cvs-public'
will continue to have an account on 'git-public'. (In fact, for now,
they are the same machine.)

We are in the process of preparing the 'real' git repository, but in
the meantime, you can start looking at our 'transitional' repository
(which is updated from CVS every 5 minutes) to start getting familiar
with git:
    http://users.emulab.net/trac/emulab/wiki/CvsToGit

For those of you who are just tracking the Emulab code read-only, with
no local changes, you will have to learn a few new commands, but you
shouldn't see very many large differences.  git is able to act as a
CVS server, so if you (a) really don't want to learn git, (b) only
need read-only access, and (c) don't need to maintain local changes to
your source, you can continue to check out the repository with cvs -
instructions for doing this are described on the page linked above.
However, be warned that you will need to do a fresh checkout from the
new repository; it won't work to point an existing CVS sandbox at the
new location. Also, while we have done basic testing on this CVS
interface, we can't guarantee there won't be problems with it.

For those of you who maintain local changes, or are Emulab committers,
you'll need to learn more about the git model, but part of the reason
we're moving to it is to make things better for you in the long run
(see below.) We've started to develop documents describing our
standard practices and policies here:
    http://users.emulab.net/trac/emulab/wiki/GITWorkflow
    http://users.emulab.net/trac/emulab/wiki/GitPolicies

There are some very good books on git, some of which are available for
free online, such as this one:
    http://www.progit.org/book

Like all other documentation on the main Emulab site, the documents
listed above are in a wiki - so if you have some bit of git knowledge
that you want to share, please do edit them!

We are moving to git for a number of reasons.  One of the biggest is
the ability to maintain branches in the code (git's branching support
is infinitely better than CVS's) - this will allow us to do better
coordination between developers. It will also make it feasible to
maintain local branches - for example, you can create a branch in your
local repository, and periodically sync up with the main branch from
Utah, or to pull in specific commits.  git also has a lot of history
and change browsing tools that are much better and faster than CVS's -
see for example 'gitk' (GUI for browsing changes), 'git bisect'
(binary search for changes), and the 'pickaxe' ('git diff -S'). 

We're also planning to maintain separate 'stable' and 'development'
repositories; the former will contain code that had passed muster by
running live at Utah for a while, and we expect most sites will just
want to track that one.