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 12:22:59 GMT
El vie, 02-05-2008 a las 13:59 +0200, Grzegorz Kossakowski escribió:
> Santiago Gala pisze:
> > I think it depends on the error you meet, I'm guessing. If you hit it
> > because git-svn is going to ask REPORT of the root of the repository,
> > there is no way to fix it. But I *think* sometimes I was hitting other
> > limits, like number of requests, and then making it higher means less
> > requests. Up to /100 requests
> > 
> > Some people (Henning?) told that actually the project being cloned has
> > to be 2 levels above root to succeed. This is consistent with my
> > successes cloning (incubator/)shindig and (portals/)bridges, but not
> > other public repos.
> 
> Yep, Cocoon is TLP and I've been getting 403 as response to git-svn REPORT requests.
Too bad nothing 
> can be (easily) done about it.
> 
> > 
> > Disallowing mod_dontdothat from IP addresses like p.a.o might help. Just
> > an idea.
> 
> Yep but cloning using git-svn puts some load on the machine. I'm not sure how capable
is p.a.o. 

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).

> Other idea would be to disable mod_dontdothat for users (committers) authenticated through
SSL. 
> Cloning using https adds quite a lot of overhead but we are not talking about process
that will be 
> done on daily basis but rather on monthly. This way everyone who is a committer would
have all means 
> to access his project history (including cloning it).
> 

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).

> 
> My personal opinion is that every committer should have a right to access history of
his project 
> however he likes despite dSCM tools needs.

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.

Regards
-- 
Santiago Gala
http://memojo.com/~sgala/blog/


Mime
View raw message