Hey,
looks like I'm late to the party, and others have already answered
the questions, but here's my sermon:
* Frederic Bouvier -- 9/3/2008 2:05 PM:
> there is another thing that is unclear to me. How GIT currently
> interface with CVS ( and tomorrow SVN ) ?
> How do you merge content from CVS in your GIT repository ?
> How do you commit changes in CVS after commiting in GIT ?
Umm ... we shouldn't think and talk too much about integration
of CVS/SVN and GIT (but more on that below, anway :-). This
is just bandaid for people who want to use the power of GIT, but
are damned to interact with an oldschool repo based on CVS or SVN.
What we should really consider is a complete switch to GIT, on
the "server" and on the "client" side.
Technically, there is no "server" or "client" in GIT. You aren't
"checking out" a snapshot, you are cloning your repo from another
one. All clones are equal, only one is more equal: the *declared*
"central" repository (i.e. Curt's on flightgear.org). But this is
only by declaration, apart from that it's the same as everyone
else has. (OK, that's a lie: everyone has his/her private or public
branches -- the main reason why we are in love with GIT. :-)
Everything that you commit you only commit to your repository.
Others can pull branches/changes from that, and you can push
yours to another repository. That's where the "server" part comes
in. Curt would give his "lieutenants" push permissions for his
clone. This and the fact that he makes the releases from his
clone are all that's special about his repo.
And because all repos are equal, Curt doesn't even have to do
the initial conversion. He can ask anyone who he trusts to do that
(ideally by importing the old flightgear-0.7 CVS repository, and
the newer flightgear-0.9 repo on top of that, so that they are
finally reunited). And once that's done, he can just make a clone
and add the push permissions. That's all. Less work than setting
up SVN, not more.
And because all repos are equal, they are complete backups. Curt
wouldn't even need to make backups. Whenever his HD dies, he can
just clone from one trusted developer. There's even a guarantee
that the source isn't manipulated, because every step in GIT is
named by the unique sha1 hash of that step and all its parents.
You just need to ask for the sha1 hash of HEAD, and you'll find
it in the cvslogs ... err gitlogs mailing list. If you clone from
a repo which has the same HEAD sha1 number, then it's exactly the
same. No way to cheat.
And because you don't only have a HEAD snapshot of the respository
(as in CVS or SVN), but a full repo clone, you can't just edit files
offline (which is all that CVS offers), or make an 'svn diff/revert'
(which subversion offers in addition). With GIT you can do about
*anything* offline. Edit, commit, diff between branches or revisions,
make branches, merge branches, whatever. Next time you are online
again, you can push your modifications to Curt's repo. This won't
be one huge commit with everything thrown together -- it will be as
fine-grained as you committed it, with all single commits retained.
But it doesn't have to be that way. You can edit your commits before
pushing -- you can merge, split, reorder them as much as you like.
You don't have to push two changes "add cool new feature A" and "fix
embarrassing bug in feature A". Just merge them before you push,
even if there are other changes in-between (see interactive rebasing).
This makes the shared history cleaner, and it makes you look like
a better coder. ;-)
All those reasons (and many more) are why projects are switching
to GIT left and right. It's not just the Linux kernel, but also
Xorg/X11, Trolltech's Qt, probably KDE and many more. (The SVN
guys are already a bit nervous! :-)
Concerning interaction with other SCM: I'm not really an expert on
that, and as stated above, we shouldn't need one. But there are
some aspects:
- There's a fake-cvs server that Curt could install alongside of
GIT. It mimics CVS and allows to access the GIT repo with a CVS
client as if it were a true CVS. I guess that sooner or later
there will be the same for SVN.
- There are cvs- and svn-import/export tools for GIT. They are used
for the initial conversion, but can also be used to keep a local
GIT repository in sync with a CVS/SVN server. But you throw away
some of the GIT power, and it's really only recommended if you
can't convince the project leader to switch to GIT right away. :-)
- Personally, I use a simple CVS<->gateway. That is a CVS checkout
which is also a GIT repository. From that I clone my GIT working
repo. When I update CVS, my GIT repo is automatically synced,
and when I push there, it's automatically committed to CVS. I
can't recommend that, though. It must be crazy to do that. :-)
m.
PS: Regarding the 2GB limit in msysgit I have to make another
correction. It's, of course, not only a limit for the file size
of stored blobs or files to be committed, but also for packs.
That means, that you can only have 2000 revisions of 1MB "random"
data files, or 200 of 10MB files, etc. And given that this is only
a temporary limitation of just one GIT incarnation on windows, it's
still not a problem.
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
