From: Petr Baudis <pasky@suse.cz>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: A Large Angry SCM <gitzilla@gmail.com>,
Junio C Hamano <junkio@cox.net>,
git@vger.kernel.org
Subject: Re: [RFC][RESEND][PATCH] Allow fetching from multiple repositories at once
Date: Sat, 23 Sep 2006 20:05:39 +0200 [thread overview]
Message-ID: <20060923180539.GC20017@pasky.or.cz> (raw)
In-Reply-To: <Pine.LNX.4.63.0609231947340.25853@wbgn013.biozentrum.uni-wuerzburg.de>
Hi!
Dear diary, on Sat, Sep 23, 2006 at 07:54:10PM CEST, I got a letter
where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> On Sat, 23 Sep 2006, Petr Baudis wrote:
>
> > Dear diary, on Sat, Sep 23, 2006 at 07:23:01PM CEST, I got a letter
> > where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> > > I still firmly believe that it would be way more efficient to fetch all
> > > those branches into _one_ proxy repository. Especially since you can reuse
> > > the objects with an alternate, which has an additional benefit over your
> > > approach.
> >
> > Huh? You can reuse the objects with my approach as well. Actually, it
> > is automagically done so.
> >
> > With proxy repository, you would still need a server-side setup to
> > maintain that repository, and specialized client-side porcelain to fetch
> > from it. My approach initially requires some core changes (which aren't
> > very pretty as it is but are not very fundamental or logically intrusive
> > either) but in the longer run it pays off since you don't need a
> > convoluted server-side setup for that.
>
> No, you do not need _any_ server-side setup. And you do not need any
> specialized client-side porcelain other than a script, which just does
> the job.
So how should the proxy repository be set up at the server side? I can
just imagine a cronjob periodically sweeping the repositories and
populate the proxy repository with new stuff (refs and objects) from
those.
Looking at what you wrote again, you talk about fetching all those
branches _into_ one proxy repository. Perhaps we misunderstand each
other. This patch is not about the "into" part, it is about being able
to fetch _FROM_ _multiple_ repositories.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
next prev parent reply other threads:[~2006-09-23 18:05 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-23 16:45 [RFC][RESEND][PATCH] Allow fetching from multiple repositories at once Petr Baudis
2006-09-23 16:57 ` A Large Angry SCM
2006-09-23 17:04 ` Petr Baudis
2006-09-23 17:23 ` Johannes Schindelin
2006-09-23 17:39 ` Petr Baudis
2006-09-23 17:54 ` Johannes Schindelin
2006-09-23 18:05 ` Petr Baudis [this message]
2006-09-23 18:14 ` Johannes Schindelin
2006-09-23 19:17 ` Petr Baudis
2006-09-23 19:35 ` Junio C Hamano
2006-09-23 17:06 ` Petr Baudis
2006-09-23 18:45 ` Jakub Narebski
2006-09-23 19:14 ` Petr Baudis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060923180539.GC20017@pasky.or.cz \
--to=pasky@suse.cz \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=gitzilla@gmail.com \
--cc=junkio@cox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).