Re: [HACKERS] A humble request

On 6/2/09 6:58 PM, Bruce Momjian wrote: Gevik Babakhani wrote: please, please, please The video is here: http://hosting3.epresence.tv/fosslc/1/watch/121.aspx Note that this version of the video requires Flash 10. A Quicktime version will be posted in the next week. -- Josh Berku

Re: [HACKERS] Managing multiple branches in git

On Tue, 2009-06-02 at 20:01 -0400, Tom Lane wrote: > Andres Freund writes: > > On 06/03/2009 01:39 AM, Tom Lane wrote: > >> But rebuilding the Linux kernel is hardly a zero-cost operation, > >> so how have Linus and co failed to notice this problem? There > >> must be some trick they're using tha

Re: [HACKERS] Managing multiple branches in git

On Tue, Jun 2, 2009 at 9:46 PM, Mark Mielke wrote: > Tom Lane wrote: >> >> I can't escape the feeling that we're missing something basic here. >> It's allegedly one of git's great strengths that it allows you to easily >> and quickly switch your attention among multiple development branches. >> We

Re: [HACKERS] It's June 1; do you know where your release is?

Andrew Dunstan wrote: Josh Berkus wrote: * plperl fails with Perl 5.10 on Windows o tgl says: no reports of this with pre-8.4 Postgres, but I bet that's just because no one tried it o dpage says: I'm rolling back the Windows installers to use 5.8 for now. Would a

Re: [HACKERS] A humble request

Gevik Babakhani wrote: > please, please, please The video is here: http://hosting3.epresence.tv/fosslc/1/watch/121.aspx --- > > David Fetter wrote: > > On Fri, May 22, 2009 at 10:39:13AM +0200, Gevik Babakhani wro

Re: [HACKERS] Managing multiple branches in git

Tom Lane wrote: I can't escape the feeling that we're missing something basic here. It's allegedly one of git's great strengths that it allows you to easily and quickly switch your attention among multiple development branches. Well, so it does, if you haven't got any derived files to rebuild. Bu

Re: [HACKERS] Managing multiple branches in git

Tom Lane wrote: Mark Mielke writes: As a "for example", you could have a local repo that you publish from. Your work spaces could be from that local repo. Yes, exactly. How do I do that? My complaint is that git fails to provide a distinction between a repo and a workspace --- they s

Re: [HACKERS] It's June 1; do you know where your release is?

On Tue, 2009-06-02 at 17:26 -0700, Josh Berkus wrote: > > * possible bug in cover density ranking? > > -- From Teodor's response, this is maybe a doc patch and not a code > patch. Teodor? Oleg? I personally think that this is a bug, because we are assigning very high rank when we are no

Re: [HACKERS] It's June 1; do you know where your release is?

Josh Berkus wrote: * plperl fails with Perl 5.10 on Windows o tgl says: no reports of this with pre-8.4 Postgres, but I bet that's just because no one tried it o dpage says: I'm rolling back the Windows installers to use 5.8 for now. Would appreciate help from anyon

Re: [HACKERS] pull raw text of a message by message-id

Alvaro Herrera wrote: > Robert Haas escribi?: > > > Oh, this is awesome. It would be handy to include a link on the HTML > > version of the page for when people are trying to pull down a patch > > that someone has foolishly included in the body of the email rather > > than attaching it. > > Ther

Re: [HACKERS] It's June 1; do you know where your release is?

On Jun 2, 2009, at 5:26 PM, Josh Berkus wrote: Tom, all, More suggested dispositions: * plperl fails with Perl 5.10 on Windows o tgl says: no reports of this with pre-8.4 Postgres, but I bet that's just because no one tried it o dpage says: I'm rolling back the Windows

Re: [HACKERS] It's June 1; do you know where your release is?

On Tue, Jun 2, 2009 at 8:26 PM, Josh Berkus wrote: >    * autovacuum can run rebuild_database_list unreasonably often > > -- A possible quick workaround would be to put a lower limit of naptime at > 1s.  This would save most people (those with 10 or less database) from > triggering rebuild_databas

Re: [HACKERS] Managing multiple branches in git

* Alvaro Herrera (alvhe...@commandprompt.com) wrote: > This doesn't fully work because some files are created in the source > directory even when building outside (e.g. src/backend/parser/scan.c) Sure, there's a couple files here and there, but those could probably be handled through gitignore, si

Re: [HACKERS] Managing multiple branches in git

On Tue, Jun 2, 2009 at 7:54 PM, Alvaro Herrera wrote: > Andres Freund escribió: > >> git clone --reference common_repo >> + small >> + staying small >> + fast >> + windows supported >> +- push/fetch needed >> - possibly unsecure if you delete from the master repository - which one >> can easily pr

Re: [HACKERS] Managing multiple branches in git

* Tom Lane [090602 20:18]: > Yeah, I thought about building out of tree, with a different build tree > for each branch and VPATH pointing at the common source tree (working > copy). That would probably work if it weren't that switching to branch > B and then back to branch A has to advance the

Re: [HACKERS] It's June 1; do you know where your release is?

Tom, all, More suggested dispositions: * plperl fails with Perl 5.10 on Windows o tgl says: no reports of this with pre-8.4 Postgres, but I bet that's just because no one tried it o dpage says: I'm rolling back the Windows installers to use 5.8 for now. Would appreciat

Re: [HACKERS] Managing multiple branches in git

Andres Freund writes: > On 06/03/2009 01:39 AM, Tom Lane wrote: >> But rebuilding the Linux kernel is hardly a zero-cost operation, >> so how have Linus and co failed to notice this problem? There >> must be some trick they're using that I haven't heard about, or >> they'd not be nearly so please

Re: [HACKERS] Managing multiple branches in git

Stephen Frost escribió: > I hope this isn't anything particularly special because I feel like I've > been doing it forever, but.. > > ==# cvs -z3 co pgsql > ==# mkdir pgsql.build > ==# cd pgsql.build > ==# ../pgsql/configure --my-args-here > ==# make > ... > > Keeps all the build files and every

Re: [HACKERS] Managing multiple branches in git

Andres Freund escribió: > git clone --reference common_repo > + small > + staying small > + fast > + windows supported > +- push/fetch needed > - possibly unsecure if you delete from the master repository - which one > can easily prevent > > git clone --shared > Essentially the same as the last

Re: [HACKERS] Managing multiple branches in git

* Tom Lane (t...@sss.pgh.pa.us) wrote: > I can't escape the feeling that we're missing something basic here. > It's allegedly one of git's great strengths that it allows you to easily > and quickly switch your attention among multiple development branches. > Well, so it does, if you haven't got any

Re: [HACKERS] Managing multiple branches in git

On Jun 2, 2009, at 4:39 PM, Tom Lane wrote: "David E. Wheeler" writes: Does that make sense? Maybe, but it still seems messy, brute force, and error-prone. I can't escape the feeling that we're missing something basic here. It's allegedly one of git's great strengths that it allows you to

Re: [HACKERS] Managing multiple branches in git

-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 > Umm, no. there are *no* ,v files in my working copies (I just checked, > to make sure I wasn't on crack). The repository has them, but the > working copy does not. SVN does keep the equivalent - that's how you can

Re: [HACKERS] Managing multiple branches in git

On 06/03/2009 01:39 AM, Tom Lane wrote: "David E. Wheeler" writes: Does that make sense? I can't escape the feeling that we're missing something basic here. It's allegedly one of git's great strengths that it allows you to easily and quickly switch your attention among multiple development bra

Re: [HACKERS] Managing multiple branches in git

On 06/03/2009 12:56 AM, Tom Lane wrote: "David E. Wheeler" writes: I should think that it'd be pretty damned easy to generate such a report from a Git repository's log. `git log` is extremely powerful, and provides a lot of interfaces for hooking things in and sorting. It's eminently do-able.

Re: [HACKERS] Managing multiple branches in git

"David E. Wheeler" writes: > Does that make sense? Maybe, but it still seems messy, brute force, and error-prone. I can't escape the feeling that we're missing something basic here. It's allegedly one of git's great strengths that it allows you to easily and quickly switch your attention among m

[HACKERS] [PATCH v2] Add bit operations util header

Add a utility header for simple bit operatios - bitops.h. At present, just contains the fls() (find last set bit) function. Signed-off-by: Jeremy Kerr --- v2: only use inline asm with gcc --- src/include/utils/bitops.h | 53 + 1 file changed, 53 i

Re: [HACKERS] Managing multiple branches in git

On Jun 2, 2009, at 4:13 PM, Tom Lane wrote: I think you missed the part of the discussion about not wishing to share a single working directory across all the branches. No, I was just ignoring it for the moment to focus on the commit and history issue. The time to rebuild derived files

Re: [HACKERS] Managing multiple branches in git

On Jun 2, 2009, at 3:55 PM, Andrew Dunstan wrote: Umm, no. there are *no* ,v files in my working copies (I just checked, to make sure I wasn't on crack). The repository has them, but the working copy does not. SVN does keep the equivalent - that's how you can work offline for doing things l

Re: [HACKERS] Managing multiple branches in git

"David E. Wheeler" writes: > On Jun 2, 2009, at 3:56 PM, Tom Lane wrote: >> Meanwhile, there seem to have been ten different solutions proposed to >> the problem of working with multiple branches/checkouts, and I plead >> confusion. Anyone want to try to sort out the pluses and minuses? > If the

Re: [HACKERS] dblink patches for comment

Tom Lane wrote: The docs patch looks okay, except this comment is a bit hazy: + -- Note: local connection must require authentication for this to work properly I think what it means is + -- Note: local connection must require password authentication for this to work properly If not, p

Re: [HACKERS] Managing multiple branches in git

"David E. Wheeler" writes: > On Jun 2, 2009, at 3:55 PM, Andrew Dunstan wrote: >> Running recursive grep on a >> subversion working copy is quite nasty. > `git grep` to avoid this issue with Git. One thing that git does do right is that the .git subdirectory exists only at the top level of you

Re: [HACKERS] Managing multiple branches in git

On Jun 2, 2009, at 3:56 PM, Tom Lane wrote: Well, it's not like CVS makes it easy ... cvs2cl is about 50K of perl, and is not very speedy or without bugs :-(. So maybe we are setting the goalposts in the wrong place by supposing that the lowest-level git history needs to be exactly what's wa

Re: [HACKERS] Managing multiple branches in git

"David E. Wheeler" writes: > I should think that it'd be pretty damned easy to generate such a > report from a Git repository's log. `git log` is extremely powerful, > and provides a lot of interfaces for hooking things in and sorting. > It's eminently do-able. Well, it's not like CVS makes

Re: [HACKERS] Managing multiple branches in git

Mark Mielke wrote: Alvaro Herrera wrote: Mark Mielke wrote: I am curious about why an end user would really care? CVS and SVN both kept local workspace directories containing metadata. If anything, I find GIT the least intrusive of these three, as the .git is only in the top-level dir

Re: [HACKERS] Managing multiple branches in git

On Jun 2, 2009, at 3:33 PM, Tom Lane wrote: A back-branch-only fix would look the same except for not having any unannotated filenames. I'm too lazy to go trolling for one just now. God Tom, you're such a bloody slacker. Sheesh! It's also possible to get it to produce histories that include

Re: [HACKERS] Managing multiple branches in git

"David E. Wheeler" writes: > On Jun 2, 2009, at 3:11 PM, Tom Lane wrote: >> Maybe that special log tool Andrew was >> speculating about would take the form of a program to aggregate the >> change histories of several repositories. > You mean so that such patches in back branches show up in the th

Re: [HACKERS] Managing multiple branches in git

On 06/02/2009 10:43 PM, Alvaro Herrera wrote: Andres Freund wrote: On 06/02/2009 09:38 PM, Alvaro Herrera wrote: What *really* bugs me is that it's so difficult to have one "pulled" tree and create a bunch of checked out copies from that. I dont see were the difficulty resides? #Setup a bas

Re: [HACKERS] Managing multiple branches in git

I think it all makes a lot more sense if you think of your local git clone as just a cache. The real repo is still separate in a real repo on a server. In that mental model the equivalent of CVS "commit" is actually git push not git commit. And the equivalent of CVS update is actually git

Re: [HACKERS] Managing multiple branches in git

On Tue, Jun 2, 2009 at 5:28 PM, Ron Mayer wrote: > Robert Haas wrote: >> And, unfortunately, I'm not sure there's a good solution.  Tom could >> create 1 local repository cloned from the origin and then N-1 copies >> cloned with --local from that one, but this sort of defeats the >> purpose of usi

Re: [HACKERS] Managing multiple branches in git

On Jun 2, 2009, at 3:11 PM, Tom Lane wrote: "David E. Wheeler" writes: Perhaps there's a master repository that corresonds to CVS HEAD, and then release branches are actually separate git repositories. Yeah, I was speculating about that one too. It might be workable. Just "cp -r" the master

Re: [HACKERS] Managing multiple branches in git

"David E. Wheeler" writes: > Perhaps there's a master repository that corresonds to CVS HEAD, and > then release branches are actually separate git repositories. Yeah, I was speculating about that one too. It might be workable. Just "cp -r" the master whenever we fork a new branch. However, t

Re: [HACKERS] Managing multiple branches in git

On Jun 2, 2009, at 2:31 PM, Tom Lane wrote: It's a bit premature to speculate about alternate history tools when we haven't figured out what the repository is going to look like. Right at the moment I'm much more concerned about the question of supporting a checkout-per-branch workflow. Tha

Re: [HACKERS] Managing multiple branches in git

On Jun 2, 2009, at 5:20 PM, Tom Lane wrote: Robert Haas writes: On Tue, Jun 2, 2009 at 4:09 PM, Tom Lane wrote: Blowing away your working directory shouldn't result in loss of your entire project history. Such an outcome could not possibly be less likely with any other system than it is

Re: [HACKERS] Managing multiple branches in git

Andrew Dunstan writes: > The only reason Tom sees a single line history is because he uses an > addon tool for CVS called cvs2cl: see . > It's not part of CVS, and I'm not sure how many others use it. I sure > don't. FWIW, I believe Bruce uses some version of i

Re: [HACKERS] Managing multiple branches in git

Robert Haas wrote: > And, unfortunately, I'm not sure there's a good solution. Tom could > create 1 local repository cloned from the origin and then N-1 copies > cloned with --local from that one, but this sort of defeats the > purpose of using git, because now if he commits a change to one of > t

Re: [HACKERS] Managing multiple branches in git

Robert Haas wrote: The arguments that were put forward for switching to git all had to do with managing patches against HEAD. AFAIK hardly anyone but the core committers deals with back-patching at all, and so a structure like this isn't going to affect anyone else --- you'd just ignore the b

Re: [HACKERS] Managing multiple branches in git

Robert Haas writes: > On Tue, Jun 2, 2009 at 4:09 PM, Tom Lane wrote: >> Blowing away your working directory shouldn't result in loss of your >> entire project history. > Such an outcome could not possibly be less likely with any other > system than it is with git. Every single developer has a

Re: [HACKERS] Managing multiple branches in git

Andres Freund escribió: > On 06/02/2009 10:13 PM, Robert Haas wrote: >> Yeah but now you have to push and pull commits between your numerous >> local working copies. Boo, hiss. > In the end thats the same with cvs and multiple checkouts? You don't pull and push in CVS, you just commit and update

Re: [HACKERS] Managing multiple branches in git

On 06/02/2009 10:13 PM, Robert Haas wrote: On Tue, Jun 2, 2009 at 3:58 PM, Andres Freund wrote: On 06/02/2009 09:38 PM, Alvaro Herrera wrote: Mark Mielke wrote: I just don't understand why you care. If the CVS directories didn't bug you before, why does the single .git directory bug you now?

Re: [HACKERS] Managing multiple branches in git

On Jun 2, 2009, at 4:32 PM, Tom Lane wrote: Robert Haas writes: I wonder whether it would help with this problem if we had a way to locate the build products outside the tree, and maybe fix things up so that you can make the build products go to a different location depending on which bran

Re: [HACKERS] dot to be considered as a word delimiter?

On Tue, Jun 02, 2009 at 04:40:51PM -0400, Sushant Sinha wrote: > Fair enough. I agree that there is a valid need for returning such tokens as > a host. But I think there is definitely a need to break it down into > individual words. This will help in cases when a document is missing a space > in be

Re: [HACKERS] dot to be considered as a word delimiter?

Sushant Sinha wrote: > So what we can do is: return the entire compound word as Host and > also break it down into individual words. So, pretty much like we handle hyphenation? -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscriptio

Re: [HACKERS] Managing multiple branches in git

Mark Mielke writes: > As a "for example", you could have a local repo that you publish from. > Your work spaces could be from that local repo. Yes, exactly. How do I do that? My complaint is that git fails to provide a distinction between a repo and a workspace --- they seem to be totally tied

Re: [HACKERS] dot to be considered as a word delimiter?

Fair enough. I agree that there is a valid need for returning such tokens as a host. But I think there is definitely a need to break it down into individual words. This will help in cases when a document is missing a space in between the words. So what we can do is: return the entire compound wor

Re: [HACKERS] Managing multiple branches in git

Andres Freund wrote: > On 06/02/2009 09:38 PM, Alvaro Herrera wrote: >> What *really* bugs me is that it's so difficult to have one "pulled" >> tree and create a bunch of checked out copies from that. > I dont see were the difficulty resides? > > #Setup a base repository > cd /../master > git [--b

Re: [HACKERS] Managing multiple branches in git

Robert Haas writes: > I wonder whether it would help with this problem if we had a way to > locate the build products outside the tree, and maybe fix things up so > that you can make the build products go to a different location > depending on which branch you're on. I'm beginning to seriously co

Re: [HACKERS] Managing multiple branches in git

Robert Haas wrote: On Tue, Jun 2, 2009 at 3:58 PM, Andres Freund wrote: #Method 1 cd /../child1 git clone --reference /../master/ git://git.postgresql.org/whatever . cd /../child2 git clone --reference /../master/ git://git.postgresql.org/whatever . This way you can fetch from the git url w

Re: [HACKERS] Locks on temp table and PREPARE

Emmanuel Cecchet writes: > Take PG 8.3.0 and try: > BEGIN; > CREATE TEMP TABLE foo (x int) ON COMMIT DROP; > PREPARE TRANSACTION 't1'; > [BEGIN;] <-- doesn't really matter if you start a new transaction or not > CREATE TEMP TABLE foo (x int); <-- blocks until t1 commits > I have been tracking dow

Re: [HACKERS] Managing multiple branches in git

Tom Lane wrote: Mark Mielke writes: I'm not following. CVS and SVN both kept such directories "in the checked out copy." Recall the CSV/*,v files? I can't speak to SVN, but that is *not* how CVS does it. There's a small CVS/ directory, but the repository (with all the ,v files) is so

Re: [HACKERS] Managing multiple branches in git

On Tue, Jun 2, 2009 at 4:09 PM, Tom Lane wrote: > Blowing away your working directory shouldn't result in loss of your > entire project history. Such an outcome could not possibly be less likely with any other system than it is with git. Every single developer has a copy of your entire history,

[HACKERS] Locks on temp table and PREPARE

Hi, As we discussed during PGCon, we are using temp tables in 2PC transactions. The temp tables are dropped before PREPARE (or have an ON COMMIT DROP option) and never cross transaction boundaries. In 8.3.1, a patch was introduced to disallow temp tables in 2PC transactions and we tried to pro

Re: [HACKERS] Managing multiple branches in git

On Tue, Jun 2, 2009 at 3:58 PM, Andres Freund wrote: > On 06/02/2009 09:38 PM, Alvaro Herrera wrote: >> >> Mark Mielke wrote: >> >>> I just don't understand why you care. If the CVS directories didn't bug >>> you before, why does the single .git directory bug you now? I'm >>> genuinely interested

Re: [HACKERS] Managing multiple branches in git

On Tue, Jun 2, 2009 at 3:38 PM, Alvaro Herrera wrote: > What *really* bugs me is that it's so difficult to have one "pulled" > tree and create a bunch of checked out copies from that. Yeah. It basically doesn't work, hacks to the contrary on this thread nonwithstanding, and I'm sympathetic to To

Re: [HACKERS] Managing multiple branches in git

Mark Mielke writes: > Alvaro Herrera wrote: >> That's not the problem. The problem is that it is kept in the same >> directory as the checked out copy. It would be a lot more usable if it >> was possible to store it elsewhere. > I'm not following. CVS and SVN both kept such directories "in the

Re: [HACKERS] Managing multiple branches in git

Tom Lane wrote: Once I have all the versions tested, I prepare a commit message and commit all the branches. This results in one commit message per branch in the pgsql-committers archives, and just one commit in the cvs2cl representation of the history --- which is what I want. I think

Re: [HACKERS] Managing multiple branches in git

On 06/02/2009 09:38 PM, Alvaro Herrera wrote: Mark Mielke wrote: I just don't understand why you care. If the CVS directories didn't bug you before, why does the single .git directory bug you now? I'm genuinely interested as I don't get it. :-) It doesn't. What bugs me is that the database (

Re: [HACKERS] Managing multiple branches in git

Alvaro Herrera wrote: Mark Mielke wrote: I just don't understand why you care. If the CVS directories didn't bug you before, why does the single .git directory bug you now? I'm genuinely interested as I don't get it. :-) It doesn't. What bugs me is that the database (the "pulled" t

Re: [HACKERS] Managing multiple branches in git

Mark Mielke wrote: > I just don't understand why you care. If the CVS directories didn't bug > you before, why does the single .git directory bug you now? I'm > genuinely interested as I don't get it. :-) It doesn't. What bugs me is that the database (the "pulled" tree if you will) is stored

Re: [HACKERS] Managing multiple branches in git

Alvaro Herrera wrote: Mark Mielke wrote: I am curious about why an end user would really care? CVS and SVN both kept local workspace directories containing metadata. If anything, I find GIT the least intrusive of these three, as the .git is only in the top-level directory, whereas CVS an

Re: [HACKERS] pg_standby -l might destory the archived file

Heikki Linnakangas writes: > Tom Lane wrote: >> That's a good point; don't we recover files under names like >> RECOVERYXLOG, not under names that could possibly conflict with regular >> WAL files? > Yes. But we rename RECOVERYXLOG to 00010057 or similar > at the end of recovery,

Re: [HACKERS] [COMMITTERS] pgsql: Fix LOCK TABLE to eliminate the race condition that could make it

Tom Lane wrote: > Simon Riggs writes: > > If we're going to require cascaded permissions like this, would it make > > sense to make GRANT cascade down the inheritance tree also? > > That's been discussed before. I forget whether we decided it was a good > idea or not, but in any case it looks l

Re: [HACKERS] Managing multiple branches in git

Andrew Dunstan writes: > Hmm. I confess that I never switch between CVS branches. Instead I keep > a separate tree for each maintained branch. Right, exactly, and that's the workflow I want to maintain with git. Having to rebuild the derived files every time I look at a different branch is too

Re: [HACKERS] Managing multiple branches in git

Tom Lane wrote: "David E. Wheeler" writes: Yeah, with git, rather than cd'ing to another directory, you'd just do `git checkout rel8_3` and work from the same directory. That's what I'd gathered, and frankly it is not an acceptable answer. Sure, the "checkout" operation is remarkab

Re: [HACKERS] Managing multiple branches in git

* Alvaro Herrera [090602 13:25]: > That's not the problem. The problem is that it is kept in the same > directory as the checked out copy. It would be a lot more usable if it > was possible to store it elsewhere. > > Yes, the .svn directories are a PITA. You can export GIT_DIR to make the .gi

Re: [HACKERS] It's June 1; do you know where your release is?

Kris Jurka writes: > On Mon, 1 Jun 2009, Robert Haas wrote: >> tgl says: whether or not we think PL/Java is bulletproof, there are >> other problems, for instance this one >> http://archives.postgresql.org/message-id/87zlnwnvjg@news-spur.riddles.org.uk >> >> That's a pretty overwhelming argum

Re: [HACKERS] Managing multiple branches in git

Andres Freund wrote: On 06/02/2009 06:33 PM, Tom Lane wrote: At the same time, I don't really buy the theory that relating commits on different branches via merges will work. In my experience it is very seldom the case that a patch applies to each back branch with no manual effort whatever, whi

Re: [HACKERS] from_collapse_limit vs. geqo_threshold

Robert Haas writes: > On Mon, Jun 1, 2009 at 3:34 PM, Selena Deckelmann wrote: >> Suggested revision of Robert's prose: >> >> Because genetic query optimization may be triggered, increasing >> from_collapse_limit should be considered relative to > linkend="guc-geqo-threshold">. > Here's my atte

Re: [HACKERS] Managing multiple branches in git

On 6/2/09, Alvaro Herrera wrote: > Mark Mielke wrote: > > > I am curious about why an end user would really care? CVS and SVN both > > kept local workspace directories containing metadata. If anything, I > > find GIT the least intrusive of these three, as the .git is only in the > > top-level

Re: [HACKERS] Managing multiple branches in git

Mark Mielke wrote: > I am curious about why an end user would really care? CVS and SVN both > kept local workspace directories containing metadata. If anything, I > find GIT the least intrusive of these three, as the .git is only in the > top-level directory, whereas CVS and SVN like to poll

Re: [HACKERS] pg_standby -l might destory the archived file

Tom Lane wrote: Simon Riggs writes: err...I don't see *any* problem at all, since pg_standby does not do step (1) in the way you say and therefore never does step (5). Any links created are explicitly deleted in all cases at the end of recovery. That's a good point; don't we recover files und

Re: [HACKERS] Managing multiple branches in git

Tom Lane wrote: I agree, .git as a subdirectory of the working directory doesn't make much sense to me. I wondered for a second about symlinking .git from several checkout directories to a common master, but AFAICT .git stores both the "repository" and status information about the current checko

Re: [HACKERS] Managing multiple branches in git

* Tom Lane [090602 12:35]: > Alvaro Herrera writes: > > Hmm, but is there a way to create those clones from a single local > > "database"? > > > (I like the monotone model much better. This mixing of working copies > > and databases as if they were a single thing is silly and uncomfortable > >

Re: [HACKERS] Managing multiple branches in git

Tom Lane wrote: > Marko Kreen writes: >> They cannot be same commits in GIT as the resulting tree is different. > The way I prepare a patch that has to be back-patched is first to make > and test the fix in HEAD. Then apply it (using diff/patch and perhaps > manual adjustments) to the first back

Re: [HACKERS] Managing multiple branches in git

On Jun 2, 2009, at 9:23 AM, Aidan Van Dyk wrote: Yeah, with git, rather than cd'ing to another directory, you'd just do `git checkout rel8_3` and work from the same directory. But that looses his "configured" and "compiled" state... But git isn't forcing him to change his workflow at all...

Re: [HACKERS] Managing multiple branches in git

On 6/2/09, Tom Lane wrote: > Alvaro Herrera writes: > > Hmm, but is there a way to create those clones from a single local > > "database"? > > > (I like the monotone model much better. This mixing of working copies > > and databases as if they were a single thing is silly and uncomfortable >

Re: [HACKERS] pg_standby -l might destory the archived file

Simon Riggs wrote: On Mon, 2009-06-01 at 14:47 +0900, Fujii Masao wrote: pg_standby can use ln command to restore an archived file, which might destroy the archived file as follows. 1) pg_standby creates the symlink to the archived file '102' 2) '102' is applied 3) the next file '103' doesn't

Re: [HACKERS] Managing multiple branches in git

On 06/02/2009 06:33 PM, Tom Lane wrote: At the same time, I don't really buy the theory that relating commits on different branches via merges will work. In my experience it is very seldom the case that a patch applies to each back branch with no manual effort whatever, which is what I gather th

Re: [HACKERS] pg_standby -l might destory the archived file

Simon Riggs writes: > err...I don't see *any* problem at all, since pg_standby does not do > step (1) in the way you say and therefore never does step (5). Any links > created are explicitly deleted in all cases at the end of recovery. That's a good point; don't we recover files under names like

Re: [HACKERS] SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5

Hans-Juergen Schoenig wrote: > hello everybody, > > from my side the goal of this discussion is to extract a consensus so > that we can go ahead and implement this issue for 8.5. > our customer here needs a solution to this problem and we have to come > up with something which can then make it i

Re: [HACKERS] Managing multiple branches in git

Alvaro Herrera writes: > Hmm, but is there a way to create those clones from a single local > "database"? > (I like the monotone model much better. This mixing of working copies > and databases as if they were a single thing is silly and uncomfortable > to use.) I agree, .git as a subdirectory

Re: [HACKERS] Managing multiple branches in git

On 06/02/2009 05:43 PM, Tom Lane wrote: Marko Kreen writes: They cannot be same commits in GIT as the resulting tree is different. I don't see any even-approximately-sane way to handle similar cases in git. From what I've learned so far, you can have one checkout at a time in a git working tr

Re: [HACKERS] Managing multiple branches in git

On 6/2/09, Tom Lane wrote: > [ it's way past time for a new subject thread ] > > Marko Kreen writes: > > They cannot be same commits in GIT as the resulting tree is different. > > This brings up something that I've been wondering about: my limited > exposure to git hasn't shown me any sane wa

Re: [HACKERS] Managing multiple branches in git

* David E. Wheeler [090602 11:56]: > On Jun 2, 2009, at 8:43 AM, Tom Lane wrote: > >> Each of these is configured (using --prefix) to install into a >> separate >> installation tree. So I can switch my attention to one branch or >> another by cd'ing to the right place and adjusting a few enviro

Re: [HACKERS] Managing multiple branches in git

On Tue, Jun 2, 2009 at 5:16 PM, Alvaro Herrera wrote: > David E. Wheeler wrote: > >> Well, you can have as many clones of a repository as you like. You can >> keep one with master checked out, another with rel8_3, another with >> rel8_2, etc. You'd just have to write a script to keep them in sync

Re: [HACKERS] Managing multiple branches in git

On Jun 2, 2009, at 9:16 AM, Alvaro Herrera wrote: Well, you can have as many clones of a repository as you like. You can keep one with master checked out, another with rel8_3, another with rel8_2, etc. You'd just have to write a script to keep them in sync (shouldn't be too difficult, each jus

Re: [HACKERS] Managing multiple branches in git

Yeah I was annoyed by the issue with having to reconfigure as well. There are various tricks you can do though with separate repositories. You could have the older branch repositories be clones of HEAD branch repository so when you push from them the changes just go to that repository then y

Re: [HACKERS] PostgreSQL Developer meeting minutes up

Aidan Van Dyk wrote: > * Markus Wanner [090602 10:23]: >> As mentioned before, I'd personally favor *all* of the back-ports to >> actually be merges of some sort, because that's what they effectively >> are. However, that also bring up the question of how we are going to do >> back-patches in

Re: [HACKERS] PostgreSQL Developer meeting minutes up

On 6/2/09, Markus Wanner wrote: > Quoting "Marko Kreen" : > > And what silly side effects are you talking about? > > > > I'm talking about spurious file duplicates popping up after a rename and a > merge, see my example in this thread. The example was not actual case from Postgres CVS history,

Re: [HACKERS] Managing multiple branches in git

David E. Wheeler wrote: > Well, you can have as many clones of a repository as you like. You can > keep one with master checked out, another with rel8_3, another with > rel8_2, etc. You'd just have to write a script to keep them in sync > (shouldn't be too difficult, each just as all the oth

Re: [HACKERS] pg_standby -l might destory the archived file

On Mon, 2009-06-01 at 14:47 +0900, Fujii Masao wrote: > pg_standby can use ln command to restore an archived file, > which might destroy the archived file as follows. > > 1) pg_standby creates the symlink to the archived file '102' > 2) '102' is applied > 3) the next file '103' doesn't exist and

  1   2   >