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: Best Practices so far?
Date Fri, 02 May 2008 14:08:35 GMT
El vie, 02-05-2008 a las 14:36 +0200, Grzegorz Kossakowski escribió:
> Santiago Gala pisze:
> > I guess it is reasonable, and the whole generated repo can be bzipped
> > and copied or cloned and git-svn gets to reconstruct the history without
> > hitting the server (I think).
> Not sure what you meant here. Do you want to say that you are going to ask infra people
for a 
> snapshot of svn repository and let git-svn to do its work offline? (that's how I read

I have a git install in my p.a.o account, and I got someone on infra to
reinstall svn with the perl bindings there. This means git-svn should
works. If the restriction could be lifted for this IP we could have an
easy way to clone projects:

ssh p.a.o git svn clone ...
git pull git+ssh://p.a.o/...

> > 
> > Even less than monthly, if there is an "official" clone to be cloned.
> > Not sure how well this works, but I think the first "git svn fetch"
> > after a "git clone" reconstructs the history using the tags in commits,
> > not hitting the server until the end of it (not sure about it).
> Yes, if there is any significant interest then we could think about sharing "official"
clone. For 
> Cocoon whole repository would be about 0.5GB (or less) of size so even putting it into
> of p.a.o account shouldn't be a problem.
> > For me being able to browse the whole history while offline or on slow
> > cellular is useful, because expresses quite well intent of changes in
> > directories or files. Even when online, most operations are blazingly
> > fast, faster than anything using history. And the working copies are
> > typically larger than the whole git repo.
> Quick browsing/searching is actually the main reason for me to choose Git. Svn fails
miserably in 
> this regard but as loon as I have my own Git repository copy I'm fine with central repository
> as svn. I understand arguments on having single, central repository but I would like
to remind all 
> of us that Git is rather flexible and can work well cooperating with svn.

+1 While I believe in general in de-centralization, I can actually buy
most of the arguments used in favor of subversion:
- conceptual simplicity for "naive" SCM users (git has a damned learning
- familiarity (already there in a lot of companies)
- better tool support (specially re: IDEs, though egit is beginning to
have nice things)
- windows "experience"

But I don't think those reasons are incompatible with experienced
developers (release managers or integrators benefit mostly of it) to use
the merging, browsing and visualizing features of git, or speed at
branch switching, commit, etc. I have not found mercurial close to git
in those aspects, sp. branches, no matter what the benchmarks or
checklists say

This is why I protested a lot every time people asked for a "transition
plan" or similar. While I would not bar evolution, I don't think we will
be ready for it until after extensive experimentation and use, and this
can only be done by having interoperation. (Or "lab rat" project
migration, which looks even more of an organizational mess)


Santiago Gala

View raw message