On Jan 27, 2009, at 12:47 PM, Jason Dillon wrote:
On Jan 28, 2009, at 12:07 AM, Kevan Miller wrote:
What does git have that svn doesn't which makes you so interested in
the subject?
IIUC, the major advantages of GIT are:
* offline commits - you can commit changes, even if online.
* cheap branching - this would make it much simpler for individuals
to create private local branches and work on implementing a
particular feature, without interfering with other development they
might be working on in the same code branch.
* fast merging - given the cheap branching, you need to do a lot of
merging, which GIT is supposed to do very well
GIT would not be a replacement of SVN. The GIT repositories are
actually mirroring svn. GIT would just be a new tool for accessing
our code.
There are some usages of GIT that would not fit well into an Apache
project. For instance, I would not want to see project members
using GIT as a private means of sharing code updates. Ultimately,
code needs to get into our svn repo -- that's where we should be
sharing code.
Why do you have a problem with users sharing code via their own GIT
repos? I guess I can kinda see your concern, but I'd expect folks
with significant changes to the codebase to want to share their GIT
repos with others *before* pushing those changes back into SVN.
Right. So, I wouldn't want a few people to decide to implement some
new function, start sharing code (privately amongst themselves), and
then dump it into svn. IIUC, GIT makes this pretty easy to do.
Currently, this sort of activity would happen in an svn sandbox or via
patches posted to a Jira. In either case the collaboration and work
should be public. I want to make sure we maintain this.
Until *everyone* is using GIT and we have community policies governing
its usage, svn and our mailing lists are where we need to be
collaborating.
--kevan
