Part of the migration from Subversion to Git will be to start
providing tarball releases of the CASPER libraries and toolflows for
people who use them to develop their own applications, but who do not
actively develop the CASPER libraries and toolflows themselves. If
that describes you, you can stop reading now if you want to. If you
consider yourself a developer of the CASPER libraries and toolflows,
read on!
Mark Wagner and I have been setting up git related services on the
casper.berkeley.edu server. The intent is for casper.berkeley.edu to
host the official/canonical/reference CASPER Git repositories, just
as it has hosted the only (and therefore official/canonical/
reference) CASPER Subversion repository. This message details our
progress and outlines future steps. Your feedback is greatly
appreciated (hint! hint!).
Current Status
==============
We currently have two small test repositories and the following git
related services running on casper.berkeley.edu:
1) gitweb - This provides a web browser view into the repositories.
It is the same web interface used by git.kernel.org (Linux kernel)
and git.denx.de (embedded Linux) among others. The URL of the CASPER
gitweb interface is...
http://casper.berkeley.edu/git/
2) git clone via HTTP - Git allows anonymous fetching (including
cloning and pulling) over HTTP. However, HTTP is not a "git aware"
protocol (leading some in the git community to refer to HTTP as a
"dumb protocol"), so cloning via HTTP should only be used as a last
resort if cloning via the git protocol is not possible (e.g. due to
intervening firewalls, etc.).
3) git clone via git protocol - Git allows anonymous fetching
(including cloning and pulling) over its own native protocol. This
is obviously a "git aware" protocol, which allows it to be smarter
and therefore more efficient than fetching over HTTP. This is the
preferred way to clone a repository unless you have "write" access to
it and want to push changes from your local clone back to the
upstream repository. Most people will probably use the git protocol
to clone repositories from casper.berkeley.edu.
4) git clone via ssh and gitosis - Git allows non-anonymous cloning
over ssh. Gitosis is a tool that makes administration of multiple
git repositories over ssh with multiple users easier. Instead of
requiring each git user with write access to have an account on the
server, a common account ("gitosis") with very limited privileges is
used. ssh access to the gitosis account is controlled by public
keys. Users requiring write access to public repositories on
casper.berkeley.edu must generate a public/private keypair (e.g.
using ssh-keygen), send the *public* key to Mark and/or me, and
configure their ssh client to use public key authentication when
connecting to casper.berkeley.edu. Details of the user's local ssh
configuration are beyond the scope of this message.
Developers wishing to get their feet wet with git are encouraged to
clone either or both of the existing test repositories. Poke around
the gitweb interface to find the exact URLs to use. Getting familiar
with the "gitk" tool is also encouraged.
Git supports a de-centralized development model with multiple
mechanisms for propagating locally committed changes "upstream". We
are still weighing various options and have not yet settled on one
preferred/recommended development pattern for propagating changes
upstream. Until then, we prefer to keep very short the list of those
with write privileges to the "official/canonical/reference" Git
repositories. Note, however, that cloning a git repository (roughly
analogous to a checking out from Subversion) results in a fully
functional local repository complete with full history, so you can
keep committing changes locally while we decide how we want to manage
the upstream propagation. Also note that cloning via one protocol
does not preclude changing to a different protocol later on if needed/
desired.
Next Steps
==========
We plan on migrating the trunk/mlib_devel_10_1 repository to git
first. During this migration, we will also include the trunk/caltech/
lib10.1 stuff in a "gavrt_library" subdirectory. This will mimic the
effect of the gavrt_library "svn:external" in mlib_devel_10_1. This
migration is scheduled to begin on 2010-06-16T19:00:00 UTC (next
Wednesday at noon Berkeley time)...
http://www.timeanddate.com/worldclock/fixedtime.html?
month=6&day=16&year=2010&hour=12&min=0&sec=0&p1=791
You will be responsible for managing any of your changes that remain
uncommitted to these areas after that time. You will also be
responsible (or at least chastised) for prematurely committing any of
your not-ready-for-prime-time changes, so please commit wisely (as
always, right? :-)).
Sometime (perhaps days) after that, we will migrate the trunk/roach/
sw/linux stuff to a git repository. We believe we have determined
the precise linux kernel git commit on which the BORPH code is based,
so we will likely graft the BORPH development onto a clone of the
"real" Linux git repository. We have already done this locally and
used this grafted repository to merge the BORPH changes with a more
recent kernel (2.6.25.20) which we have successfully built and booted
on a ROACH.
After that, we will migrate the trunk/roach/sw/uboot tree. It is
also a snapshot of an external git repository. We will similarly
graft the ROACH changes onto a "real" u-boot git repository.
After that, we will continue migrating other parts of the Subversion
repository to Git.
Note that just before each Subversion area is migrated, we will make
it read-only in Subversion.
Dave
