www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Santiago Gala <santiago.g...@gmail.com>
Subject Re: git for other open source projects
Date Thu, 28 Feb 2008 10:36:05 GMT

El jue, 28-02-2008 a las 01:51 +0200, Jukka Zitting escribió:
> Hi,
> On Thu, Feb 28, 2008 at 1:21 AM, Jeff Hammerbacher
> <jeff.hammerbacher@gmail.com> wrote:
> >  saw some comments on the thrift mailing list that indicated apache had
> >  started a discussion about using git.
> Don't get too carried away. There are no current plans about switching
> away from Subversion as the version control system of all Apache
> software. At the moment we're discussing how to best achieve certain
> advanced version control use cases. That might include better support
> for tools like git-svn or perhaps even a git mirror of our Subversion
> repository, but that's all speculation for now.

I have been using git-svn for offline/non-official use of some
repositories, google code and other ones. It works great for solitary
use, but the manual warns to avoid cross push-pull between several
git-svn repositories, and advises to do it always through the svn
repository. I am not concerned, as my use case is mostly ongoing
patches/"vendor" patches/offline commits.

There is one problem I'm seeing when trying to use git-svn with apache
repositories, though: the initial clone (or init+fetch) works, but later
attempts to "git svn rebase" are failing with "400 Bad Request" when it
tries to do a REPORT on the root of the repository.

IIRC REPORT of the root was disabled to avoid people checking out the
whole big repo, but this is breaking git-svn too. I'm not sure how to
debug this as git-svn is written in perl and is, thus, unreadable :).
Further, the calls are deep inside svn perl APIs.

> We're certainly interested in hearing more about how various open
> source projects leverage different version control systems and learn
> from their experiences. Especially I'd like to know what are the key
> use cases that are best supported by git or some other tool. What are
> the practical situations where git is better than the alternatives?

It is damned fast. This is a substantial part of it.

"git checkout feature-n-branch" is virtually instantaneous. Ditto for
"git diff", "git log", etc.


> BR,
> Jukka Zitting
Santiago Gala

View raw message