Aidan Van Dyk wrote:
HINT: It's all been done and posted to -hackers before too... Along
with comparisons on on whte "one-time" conversions fare (parsecvs,
cvs2svn/git), etc, as well as long discussion on which keyword you want
expanded, and which you don't, etc. bla bla bla...
And in some
Alvaro Herrera wrote:
Andrew Dunstan escribió:
I pulled together a quick hack, and here is what I get from my
mirrors. I'm not sure why we get those diffs - it's a bit odd,
although fairly insignificant.
Well, it's a $Log$ CVS keyword -- it's not surprising that it's failing
to prov
Andrew Dunstan escribió:
> I pulled together a quick hack, and here is what I get from my
> mirrors. I'm not sure why we get those diffs - it's a bit odd,
> although fairly insignificant.
Well, it's a $Log$ CVS keyword -- it's not surprising that it's failing
to provide exactly identical output,
Aidan Van Dyk wrote:
But your case of trying to "automatically" build/track the branch heads
for the buildfarm w/ git has a lot more strict requirements of the
*incremental* *conversion* *of* *CVS* than any of us had/have...
Actually, the thing that has recently annoyed me most has nothi
Magnus Hagander writes:
> On Mon, May 3, 2010 at 17:05, Andrew Dunstan wrote:
>> I pulled together a quick hack, and here is what I get from my mirrors. I'm
>> not sure why we get those diffs - it's a bit odd, although fairly
>> insignificant.
> I don't think we can call anything insignificant -
On Mon, May 3, 2010 at 17:05, Andrew Dunstan wrote:
>
>
> Magnus Hagander wrote:
>>
>> On Mon, May 3, 2010 at 16:03, Aidan Van Dyk wrote:
>>
>>>
>>> * Andrew Dunstan [100503 09:02]:
>>>
I can probably pull together a script that exports from both git and cvs
and compares.
>>>
Tom Lane escribió:
> Andrew Dunstan writes:
> > Robert Haas wrote:
> >> - we need to make sure that all the committers understand how to keep
> >> the history the way we want it - i.e. linear, without merges, and
> >> possibly even implement programmatic safeguards against doing anything
> >> else
On Mon, May 3, 2010 at 17:55, Andrew Dunstan wrote:
>
> Robert Haas wrote:
>> - we need to make sure that all the committers understand how to keep
>> the history the way we want it - i.e. linear, without merges, and
>> possibly even implement programmatic safeguards against doing anything
>> else
Andrew Dunstan writes:
> Robert Haas wrote:
>> - we need to make sure that all the committers understand how to keep
>> the history the way we want it - i.e. linear, without merges, and
>> possibly even implement programmatic safeguards against doing anything
>> else
> That too will be part of my
Robert Haas wrote:
Heikki and I are both BIG git users, and I think Andrew, Simon, and
Alvaro all use it too, though I'm not sure to what extent.
I am using it increasingly. Of course, I need to convert some of my
customers
A couple of random things I'm concerned about:
- the b
On Mon, May 3, 2010 at 10:03 AM, Aidan Van Dyk wrote:
> Not to rain on anyone's git-parade, I'm a huge git fan, but until the
> busy committers, like Tom, Bruce, Heikki, Robert, Andrew, Simon, Alvaro,
> (and all the rest I'm missing or don't know how to spell of the top of
> my head) actually *all
* Andrew Dunstan [100503 11:05]:
> If it has been done why isn't it being run?
I suspect (but can only speak for myself) it's simply because to most of
us using git for development, it's irrelevant... We're using it to
track/build/develop, and the "history" and keywords aren't relevant to
us tr
Magnus Hagander wrote:
On Mon, May 3, 2010 at 16:03, Aidan Van Dyk wrote:
* Andrew Dunstan [100503 09:02]:
I can probably pull together a script that exports from both git and cvs
and compares.
HINT: It's all been done and posted to -hackers before too... Along
with compari
Aidan Van Dyk wrote:
* Andrew Dunstan [100503 09:02]:
I can probably pull together a script that exports from both git and cvs
and compares.
HINT: It's all been done and posted to -hackers before too... Along
with comparisons on on whte "one-time" conversions fare (parsecvs,
c
On Mon, May 3, 2010 at 10:25 AM, Tom Lane wrote:
> Magnus Hagander writes:
>> The thing we've always agreed upon is to at least start by migrating
>> something that's as close to our current workflow as possible to git,
>> and *then* consider changing anything in the workflow. We're not going
>>
On Mon, May 3, 2010 at 16:25, Tom Lane wrote:
> Magnus Hagander writes:
>> The thing we've always agreed upon is to at least start by migrating
>> something that's as close to our current workflow as possible to git,
>> and *then* consider changing anything in the workflow. We're not going
>> to
Magnus Hagander writes:
> The thing we've always agreed upon is to at least start by migrating
> something that's as close to our current workflow as possible to git,
> and *then* consider changing anything in the workflow. We're not going
> to change both at once.
Yeah. One of the main constrai
On Mon, May 3, 2010 at 16:13, Tom Lane wrote:
> Aidan Van Dyk writes:
>> If you want, I know a guy in Ottawa that does really fantastic git
>> presentations... He's done them to many of the local *UGs, Is there
>> interest from the core committers in getting one done at PGcon?
>
> I'd be interes
Aidan Van Dyk writes:
> If you want, I know a guy in Ottawa that does really fantastic git
> presentations... He's done them to many of the local *UGs, Is there
> interest from the core committers in getting one done at PGcon?
I'd be interested.
regards, tom lane
--
Se
On Mon, May 3, 2010 at 16:03, Aidan Van Dyk wrote:
> * Andrew Dunstan [100503 09:02]:
>>
>
>> I can probably pull together a script that exports from both git and cvs
>> and compares.
>
> HINT: It's all been done and posted to -hackers before too... Along
> with comparisons on on whte "one-time"
* Andrew Dunstan [100503 09:02]:
>
> I can probably pull together a script that exports from both git and cvs
> and compares.
HINT: It's all been done and posted to -hackers before too... Along
with comparisons on on whte "one-time" conversions fare (parsecvs,
cvs2svn/git), etc, as well as lo
Magnus Hagander wrote:
On Fri, Apr 30, 2010 at 19:46, Andrew Dunstan wrote:
Kevin Grittner wrote:
The reported source of the software seems to have gone away. I can
let you have my copy, which reliably reproduces the error, so we
have a good failure test case.
If it's not
On Fri, Apr 30, 2010 at 19:46, Andrew Dunstan wrote:
>
>
> Kevin Grittner wrote:
>>
>>> The reported source of the software seems to have gone away. I can
>>> let you have my copy, which reliably reproduces the error, so we
>>> have a good failure test case.
>>>
>>
>> If it's not as recent as thi
Kevin Grittner wrote:
The reported source of the software seems to have gone away. I can
let you have my copy, which reliably reproduces the error, so we
have a good failure test case.
If it's not as recent as this:
http://ww2.fs.ei.tum.de/~corecode/hg/fromcvs/log/132
we might want
Andrew Dunstan wrote:
> If any Ruby hacker feels like fixing it please speak up.
I can't take it on any time soon. If nobody else picks it up, I can
get to it "eventually". Anyone taking it on might want to read
through the thread which starts at:
http://archives.postgresql.org/pgsql-hacke
Tom Lane wrote:
Heikki Linnakangas writes:
Cédric Villemain wrote:
2010/4/30 Stefan Kaltenbrunner :
I don't think the git repo was ever considered working for the backbranches
at all...
Really ?!
Then we have to remove the backbranches from the git.
http://wiki.post
Heikki Linnakangas writes:
> Cédric Villemain wrote:
>> 2010/4/30 Stefan Kaltenbrunner :
>>> I don't think the git repo was ever considered working for the backbranches
>>> at all...
>>
>> Really ?!
>> Then we have to remove the backbranches from the git.
>> http://wiki.postgresql.org/wiki/Workin
Cédric Villemain wrote:
> 2010/4/30 Stefan Kaltenbrunner :
>> I don't think the git repo was ever considered working for the backbranches
>> at all...
>
> Really ?!
> Then we have to remove the backbranches from the git.
> http://wiki.postgresql.org/wiki/Working_with_Git#Using_Back_Branches
Yeah,
2010/4/30 Stefan Kaltenbrunner :
> Alexey Klyukin wrote:
>>
>> I think postgres git repo is broken.
>>
>> The compilation of REL7_4_STABLE from git fails on my system with:
>>
>> make -C src all
>> make -C port all
>> make[2]: *** No rule to make target `sprompt.o', needed by `libpgport.a'.
>> Sto
Alexey Klyukin wrote:
I think postgres git repo is broken.
The compilation of REL7_4_STABLE from git fails on my system with:
make -C src all
make -C port all
make[2]: *** No rule to make target `sprompt.o', needed by `libpgport.a'. Stop.
There is no sprompt.c in src/port in the sources obtai
I think postgres git repo is broken.
The compilation of REL7_4_STABLE from git fails on my system with:
make -C src all
make -C port all
make[2]: *** No rule to make target `sprompt.o', needed by `libpgport.a'. Stop.
There is no sprompt.c in src/port in the sources obtained from git. However,
31 matches
Mail list logo
