Robert Haas wrote:
Tom and, I believe, also Andrew have expressed some concerns about the
space that will be taken up by having multiple copies of the git
repository on their systems. While most users can probably get by
with a single repository, committers will likely need one for each
back-branch that they work with, and we have quite a few of those.
After playing around with this a bit, I've come to the conclusion that
there are a couple of possible options but they've all got some
drawbacks.
1. Clone the origin. Then, clone the clone n times locally. This
uses hard links, so it saves disk space. But, every time you want to
pull, you first have to pull to the "main" clone, and then to each of
the "slave" clones. And same thing when you want to push.
You can have a cron job that does the first pull fairly frequently. It
should be a fairly cheap operation unless the git protocol is dumber
than I think.
The second pull is the equivalent of what we do now with "cvs update".
Given that, you could push commits direct to the authoritative repo and
wait for the cron job to catch up your local base clone.
I think that's the pattern I will probably try to follow.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
