On ons, 2010-07-21 at 23:06 +0200, Dimitri Fontaine wrote:
> Alvaro Herrera 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 buil
Alvaro Herrera 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 -hackers led me to thinki
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
> bui
Aidan Van Dyk writes:
> * Robert Haas [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 nui
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
On Wed, Jul 21, 2010 at 6:56 AM, Abhijit Menon-Sen 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 wiki and pos
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 wa
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. An
On Wed, Jul 21, 2010 at 12:39, Robert Haas wrote:
> On Wed, Jul 21, 2010 at 6:17 AM, Abhijit Menon-Sen 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,
On Wed, Jul 21, 2010 at 6:17 AM, Abhijit Menon-Sen 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 pull t
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-b
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
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
Robert Haas 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 subscription:
http://ww
* Robert Haas [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 you're going back 5-
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 wi
16 matches
Mail list logo
