On 6/2/09, Marko Kreen wrote:
> On 6/1/09, Markus Wanner wrote:
> > a newish conversion with cvs2git is available to check here:
> >
> > git://www.bluegap.ch/
> >
> > (it's not incremental and will only stay for a few days)
Btw this conversion seems broken as it contains random merge co
Hi,
Quoting "Greg Stark" :
No, I'm not. I'm questioning whether a serializable transaction
isolation level that makes no guarantee that it won't fire spuriously
is useful.
It would certainly be an improvement compared to our status quo, where
truly serializable transactions aren't supported
Hi,
Josh Berkus writes:
>> The stumbling block has been to identify a reasonably clean way
>> of determining which datatype changes don't require a scan.
>
> Yep. One possibility I'm thinking is supplying a function for each type
> which takes two typemods (old and new) and returns a value (none
Hi,
Quoting "Marko Kreen" :
I don't care half as much about the keyword expansion stuff - that's
doomed to disappear anyway.
But this is one aspect we need to get right for the conversion.
What's your definition of "right"? I personally prefer the keyword
expansion to match a cvs checkout
On Tue, Jun 2, 2009 at 1:13 AM, Kevin Grittner
wrote:
> Greg Stark wrote:
>
>> Just as carefully written SQL code can be written to avoid deadlocks
>> I would expect to be able to look at SQL code and know it's safe
>> from serialization failures, or at least know where they might
>> occur.
>
> T
On 6/2/09, Markus Wanner wrote:
> Quoting "Marko Kreen" :
> > > I don't care half as much about the keyword expansion stuff - that's
> > > doomed to disappear anyway.
> > >
> >
> > But this is one aspect we need to get right for the conversion.
> >
>
> What's your definition of "right"? I perso
Hi,
Quoting "Marko Kreen" :
Btw this conversion seems broken as it contains random merge commits.
Well, that's a feature, not a bug ;-)
When a commit adds a file to the master *and* then to the branch as
well, cvs2git prefers to represent this as a merge from the master
branch, instead of
Hi,
Quoting "Marko Kreen" :
This is Definitely Wrong (tm). You seem to be thinking that comparing
GIT checkout to random parallel CVS checkout (eg. from .tgz.) is the
main use-case. It is not. Browsing history and looking and diffs
between versions is. And expanded CVS keywords would be tota
On 6/2/09, Markus Wanner wrote:
> Quoting "Marko Kreen" :
> > Btw this conversion seems broken as it contains random merge commits.
> >
>
> Well, that's a feature, not a bug ;-)
>
> When a commit adds a file to the master *and* then to the branch as well,
> cvs2git prefers to represent this as
On Mon, Jun 01, 2009 at 08:22:23PM -0500, Kevin Grittner wrote:
> Sushant Sinha wrote:
>
> > I think that dot should be considered by as a word delimiter because
> > when dot is not followed by a space, most of the time it is an error
> > in typing. Beside they are not many valid english words
* Markus Wanner [090602 07:08]:
> Hi,
>
> Quoting "Marko Kreen" :
>>> I don't care half as much about the keyword expansion stuff - that's
>>> doomed to disappear anyway.
>>
>> But this is one aspect we need to get right for the conversion.
>
> What's your definition of "right"? I personally pref
"Markus Wanner" wrote:
> What I'm more concerned is the requirement of the proposed algorithm
> to keep track of the set of tuples read by any transaction and keep
> that set until sometime well after the transaction committed (as
> questioned by Neil). That doesn't sound like a negligible over
Jeremy Kerr writes:
> The following patch changes psecure_write to be more like psecure_read -
> it only alters the signal mask if the connection is over SSL. It's only
> an RFC, as I'm not entirely sure about the reasoning behind blocking
> SIGPIPE for the non-SSL case - there may be other consid
Hi,
Quoting "Aidan Van Dyk" :
Pick your poison (after all, it's CVS), either way, I think the 2 of
*us* are going to disagree which is best here ;-)
Marko already convinced me of -kk, I'm trying that with cvs2git.
But, which ever way (exact to -kk or exact to -kv), the conversion
should be e
On Mon, 2009-06-01 at 20:30 -0700, Ron Mayer wrote:
> What I'd find strange about "6.67 rows" in your example is more that on
> the estimated rows side, it seems to imply an unrealistically precise estimate
> in the same way that "667 rows" would seem unrealistically precise to me.
> Maybe roundi
Tatsuo Ishii writes:
> I have encountered strange errors while testing PostgreSQL 8.4 beta2.
> ERROR: tuple offset out of range: 0
> (occasionally ERROR: tuple offset out of range: 459)
This is evidently coming from tbm_add_tuples, indicating that it's being
passed bogus TID values from the GI
Greg Stark wrote:
> On Tue, Jun 2, 2009 at 1:13 AM, Kevin Grittner
> wrote:
>> Greg Stark wrote:
>>
>>> Just as carefully written SQL code can be written to avoid
deadlocks
>>> I would expect to be able to look at SQL code and know it's safe
>>> from serialization failures, or at least know wh
Tom,
> The consideration is that the application fails completely on server
> disconnect (because it gets SIGPIPE'd). This was long ago deemed
> unacceptable, and we aren't likely to change our opinion on that.
OK, understood. I'm guessing MSG_NOSIGNAL on the send() isn't portable
enough here?
* Markus Wanner [090602 09:37]:
> Marko already convinced me of -kk, I'm trying that with cvs2git.
Good ;-)
> I just really didn't want to care about keyword expansion. Besides
> lacking consistency, it's one of the worst misfeatures of CVS, IMNSHO.
> ;-)
Absolutely... And one of the reas
pg_migrator requies tables using tsvector data types to be rebuilt, and
there has been discussion of how to prevent people from accessing those
columns before they are rebuilt. We discussed renaming the tables
(affects all columns) or columns, using rules (not fine-grained enough),
or using column
On Jun 2, 2009, at 9:41 AM, Simon Riggs wrote:
On Mon, 2009-06-01 at 20:30 -0700, Ron Mayer wrote:
What I'd find strange about "6.67 rows" in your example is more
that on
the estimated rows side, it seems to imply an unrealistically
precise estimate
in the same way that "667 rows" would s
Bruce Momjian wrote:
> pg_migrator requies tables using tsvector data types to be rebuilt, and
> there has been discussion of how to prevent people from accessing those
> columns before they are rebuilt. We discussed renaming the tables
> (affects all columns) or columns, using rules (not fine-gra
On 6/2/09, Tom Lane wrote:
> Jeremy Kerr writes:
> > The following patch changes psecure_write to be more like psecure_read -
> > it only alters the signal mask if the connection is over SSL. It's only
> > an RFC, as I'm not entirely sure about the reasoning behind blocking
> > SIGPIPE for th
Jeremy Kerr writes:
>> The consideration is that the application fails completely on server
>> disconnect (because it gets SIGPIPE'd). This was long ago deemed
>> unacceptable, and we aren't likely to change our opinion on that.
> OK, understood. I'm guessing MSG_NOSIGNAL on the send() isn't por
On 6/2/09, Tom Lane wrote:
> Jeremy Kerr writes:
>
> >> The consideration is that the application fails completely on server
> >> disconnect (because it gets SIGPIPE'd). This was long ago deemed
> >> unacceptable, and we aren't likely to change our opinion on that.
>
> > OK, understood. I'm g
Marko Kreen writes:
> On 6/2/09, Tom Lane wrote:
>> We've had problems before with userland headers not being in sync
>> with what the kernel knows.
> Well, we could just test in configure perhaps?
The single most common way to get into that kind of trouble is to
compile on machine A then insta
Hi,
Quoting "Marko Kreen" :
Not a problem for git I think
Knowing that git doesn't track files as "hard" as monotone, I
certainly doubt that.
- it assumes they are same if they have
same contents...
Why do you assume they have the same contents? Obviously these are
different branches,
Bruce Momjian writes:
> pg_migrator requies tables using tsvector data types to be rebuilt, and
> there has been discussion of how to prevent people from accessing those
> columns before they are rebuilt. We discussed renaming the tables
> (affects all columns) or columns, using rules (not fine-g
Tom,
> A feature that is exercised via setsockopt is probably fairly safe,
> since you can check for failure of the setsockopt call and then do
> it the old way. MSG_NOSIGNAL is a recv() flag, no?
It's a flag to send().
> The question is whether you could expect that the recv() would fail if
>
Robert Haas writes:
> On Jun 2, 2009, at 9:41 AM, Simon Riggs wrote:
>> You're right that the number of significant digits already exceeds the
>> true accuracy of the computation. I think what Robert wants to see is
>> the exact value used in the calc, so the estimates can be checked more
>> thor
On 6/2/09, Tom Lane wrote:
> Marko Kreen writes:
> > On 6/2/09, Tom Lane wrote:
>
> >> We've had problems before with userland headers not being in sync
> >> with what the kernel knows.
>
> > Well, we could just test in configure perhaps?
>
>
> The single most common way to get into that kind
Jeremy Kerr writes:
>> MSG_NOSIGNAL is a recv() flag, no?
> It's a flag to send().
Doh, need more caffeine.
>> The question is whether you could expect that the recv() would fail if
>> it had any unrecognized flags. Not sure if I trust that. SO_NOSIGPIPE
>> seems safer.
> Yep, a once-off test
* Markus Wanner [090602 10:23]:
> # Bang, you suddenly have 'testfile' and 'movedfile', go figure!
>
> I leave it as an exercise for the reader to try the same with a single
> historic origin of the file, as cvs2git does the conversion.
Sure, and we can all construct example where that move i
...Robert
On Jun 2, 2009, at 10:38 AM, Tom Lane wrote:
Robert Haas writes:
On Jun 2, 2009, at 9:41 AM, Simon Riggs
wrote:
You're right that the number of significant digits already exceeds
the
true accuracy of the computation. I think what Robert wants to see
is
the exact value used
On Tue, Jun 2, 2009 at 2:44 PM, Kevin Grittner
wrote:
>
>> Even in your environment I could easily imagine, say, a monthly job
> to
>> delete all records older than 3 months. That job could take hours or
>> even days. It would be pretty awful for it to end up needing to be
>> retried. All I'm sayi
Aidan Van Dyk escribió:
> * Markus Wanner [090602 10:23]:
>
> > # Bang, you suddenly have 'testfile' and 'movedfile', go figure!
> >
> > I leave it as an exercise for the reader to try the same with a single
> > historic origin of the file, as cvs2git does the conversion.
>
> Sure, and we can
Aidan Van Dyk writes:
> * Markus Wanner [090602 10:23]:
>> You consider it a mess, I consider it a better and more valid
>> representation of the mess that CVS is.
> So much better that it makes the history as useless as CVS... I think
> one of the reasons people are wanting tomove from CVS to
bruce wrote:
> Tom Lane wrote:
> > Bruce Momjian writes:
> > > Tom Lane wrote:
> > >> (Come to think of it, --link can fail on Unix too, if the user tries to
> > >> put the new database on a different filesystem. Have you got guards in
> > >> there to make sure this is discovered before the point
Tom Lane wrote:
> Bruce Momjian writes:
> > pg_migrator requies tables using tsvector data types to be rebuilt, and
> > there has been discussion of how to prevent people from accessing those
> > columns before they are rebuilt. We discussed renaming the tables
> > (affects all columns) or column
Hi,
Quoting "Aidan Van Dyk" :
Sure, and we can all construct example where that move is both right and
wrong...
Huh? The problem is the file duplication. The move is an action of a
committer - it's neither right nor wrong in this example.
I cannot see any use case for seemingly random file
On Tue, Jun 2, 2009 at 4:02 PM, Alvaro Herrera
wrote:
>
>
> The Monotone folk call this "daggy fixes" and it seems a clean way to
> handle things.
>
> http://www.monotone.ca/wiki/DaggyFixes/
Is this like what git calls an octopus? I've been wondering what the
point of such things were.
Or maybe
Hi,
I made a faster version of AllocSetFreeIndex for x86 architecture.
Attached files are benchmark programs and patch file.
alloc_test.pl: benchmark script
alloc_test.c: benchmark program
aset_free_index.patch: patch for util/mmgr/aset.c
This benchmark compares the original function with a
On 6/2/09, Tom Lane wrote:
> Aidan Van Dyk writes:
> > * Markus Wanner [090602 10:23]:
>
> >> You consider it a mess, I consider it a better and more valid
> >> representation of the mess that CVS is.
>
> > So much better that it makes the history as useless as CVS... I think
> > one of the
On 6/2/09, Markus Wanner wrote:
> [academic nitpicking]
Sorry, not going there. Just look at the state of VCS systems
that have prioritized academic issues insead of practicality...
(arch/darcs/monotone/etc..)
> > So please turn the merge logic off. If this cannot be turned off,
> > cvs2git is
Hi,
> I made a faster version of AllocSetFreeIndex for x86 architecture.
Neat, I have a version for PowerPC too.
In order to prevent writing multiple copies of AllocSetFreeIndex, I
propose that we add a fls() function ("find last set"); this can be
defined in an architecture-independent manner
[ 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 way to work with multiple
release branches.
T
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
---
src/include/utils/bitops.h | 52 +
1 file changed, 52 insertions(+)
diff --git a/src/include
Results in a ~2% performance increase by using the powerpc fls()
implementation.
Signed-off-by: Jeremy Kerr
---
src/backend/utils/mmgr/aset.c |8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/src/backend/utils/mmgr/aset.c b/src/backend/utils/mmgr/aset.c
index 0e2d4d
On Tue, Jun 2, 2009 at 11:08 AM, Tom Lane wrote:
> Aidan Van Dyk writes:
>> * Markus Wanner [090602 10:23]:
>>> You consider it a mess, I consider it a better and more valid
>>> representation of the mess that CVS is.
>
>> So much better that it makes the history as useless as CVS... I think
>>
Hi,
Quoting "Tom Lane" :
FWIW, the tool that I customarily use (cvs2cl) considers commits on
different branches to be "the same" if they have the same commit message
and occur sufficiently close together (within a few minutes). My
committing habits have been designed around that behavior for ye
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 environment
variables such as PATH and PGDATA.
Yeah,
Greg Stark wrote:
> On Tue, Jun 2, 2009 at 2:44 PM, Kevin Grittner
> wrote:
>> We have next to nothing which can be deleted after three months.
> That's reassuring for a courts system.
:-)
> But i said "I could easily imagine". The point was that even in a
> big complex system with thou
"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 remarkably fast, but it does noth
Hi,
Quoting "Marko Kreen" :
Sorry, not going there. Just look at the state of VCS systems
that have prioritized academic issues insead of practicality...
(arch/darcs/monotone/etc..)
I already am there. And I don't want to go back, thanks. But my bias
for monotone certainly shines through, y
Jeremy Kerr writes:
> Add a utility header for simple bit operatios - bitops.h.
This will fail outright on any non-gcc compiler.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.post
On Jun 2, 2009, at 9:03 AM, 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" o
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
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
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,
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
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
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
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
* 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
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
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
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
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
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
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
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
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
>
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...
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
* 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
> >
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
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
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
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
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
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
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
* 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
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
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
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
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,
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
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
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
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 (
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
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
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
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
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
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,
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
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
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
1 - 100 of 156 matches
Mail list logo
