On ons, 2010-07-21 at 23:06 +0200, Dimitri Fontaine wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
This does not work as cleanly as you suppose, because some build
objects are stored in the source tree. configure being one of them.
So if you switch branches, configure is rerun
On Wed, Jul 21, 2010 at 6:17 AM, Abhijit Menon-Sen a...@toroid.org wrote:
At 2010-07-20 13:04:12 -0400, robertmh...@gmail.com wrote:
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
On Wed, Jul 21, 2010 at 12:39, Robert Haas robertmh...@gmail.com wrote:
On Wed, Jul 21, 2010 at 6:17 AM, Abhijit Menon-Sen a...@toroid.org wrote:
At 2010-07-20 13:04:12 -0400, robertmh...@gmail.com wrote:
1. Clone the origin. Then, clone the clone n times locally. This
uses hard links, so
At 2010-07-20 13:04:12 -0400, robertmh...@gmail.com wrote:
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
At 2010-07-21 06:39:28 -0400, robertmh...@gmail.com wrote:
Perhaps we need to write up directions on how to do that.
I'll write them if you tell me where to put them. It's trivial.
Well, per previous discussion, we're not going to change that at this
point, or maybe ever.
Sure. I just
On Wed, Jul 21, 2010 at 6:56 AM, Abhijit Menon-Sen a...@toroid.org wrote:
At 2010-07-21 06:39:28 -0400, robertmh...@gmail.com wrote:
Perhaps we need to write up directions on how to do that.
I'll write them if you tell me where to put them. It's trivial.
Post 'em here or drop them on the
At 2010-07-21 06:57:53 -0400, robertmh...@gmail.com wrote:
Post 'em here or drop them on the wiki and post a link.
1. Clone the remote repository as usual:
git clone git://git.postgresql.org/git/postgresql.git
2. Create as many local clones as you want:
git clone postgresql foobar
Aidan Van Dyk ai...@highrise.ca writes:
* Robert Haas robertmh...@gmail.com [100720 13:04]:
3. Clone the origin once. Apply patches to multiple branches by
switching branches. Playing around with it, this is probably a
tolerable way to work when you're only going back one or two branches
Excerpts from Dimitri Fontaine's message of mié jul 21 15:00:48 -0400 2010:
Well, there's also the VPATH possibility, where all your build objects
are stored out of the way of the repo. So you could checkout the branch
you're interrested in, change to the associated build directory and
build
Alvaro Herrera alvhe...@commandprompt.com writes:
This does not work as cleanly as you suppose, because some build
objects are stored in the source tree. configure being one of them.
So if you switch branches, configure is rerun even in a VPATH build,
which is undesirable.
Ouch. Reading
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
* Robert Haas robertmh...@gmail.com [100720 13:04]:
3. Clone the origin once. Apply patches to multiple branches by
switching branches. Playing around with it, this is probably a
tolerable way to work when you're only going back one or two branches
but it's certainly a big nuisance when
Robert Haas robertmh...@gmail.com wrote:
2. Clone the origin n times. Use more disk space. Live with it.
:-)
But each copy uses almost 0.36% of the formatted space on my 150GB
drive!
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On tis, 2010-07-20 at 13:28 -0400, Aidan Van Dyk wrote:
But *all* dependancies need to be proper in the build system, or you
end
up needing a git-clean-type-cleanup between branch switches, forcing a
new configure run too, which takes too much time...
This realization, while true, doesn't
On tis, 2010-07-20 at 13:04 -0400, Robert Haas wrote:
2. Clone the origin n times. Use more disk space. Live with it. :-)
Well, I plan to use cp -a to avoid cloning over the network n times, but
other than that that was my plan. My .git directory currently takes 283
MB, so I think I can just
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
16 matches
Mail list logo
