> LPP> I took a look at it. CURSOR-FETCH-QUERY is complicated enough as it
> LPP> is, so let's reduce it to some common primitives as far as possible
> LPP> and implement our NULL cases manually.
>
> it seems only it's where-generating part needs to be replaced (as well as
> parameters value-co
RS> On this subject, is there a particular branch that I should be using
RS> for postmodern?
first of all, definitely a version from darcs rather than a 0.9.1 release.
release version has lots of bugs.
as for stable/unstable branches, there shouldn't be a big difference as most
stuff is same an
??>> and taking into account other cursor operations, instead of 3 query
??>> templates we now have something like 12 different queries now, and
??>> i see any pattern how they can be merged :(
??>> or maybe it makes sense to ditch templated query generations and just
??>> write these conditio
> and taking into account other cursor operations, instead of 3 query
> templates we now have something like 12 different queries now, and
> i see any pattern how they can be merged :(
> or maybe it makes sense to ditch templated query generations and just write
> these conditions manually
I took
> On this subject, is there a particular branch that I should be using
> for postmodern? I've noticed occasional issues where it'll complain
> that a table already exists, generally after a non-elephant error has
> occurred within a transaction.
What branch are you using? 0.9.1, stable or unstabl
LPP> I must've missed something or unintentionally used a db
LPP> with older stuff already in it.
yep, old format database could be the case if you've got it broken
at start.
but it seems our current tests are broken, so you get always get some
error on the first run regardless of backend used.
On this subject, is there a particular branch that I should be using
for postmodern? I've noticed occasional issues where it'll complain
that a table already exists, generally after a non-elephant error has
occurred within a transaction.
Rob
___
elephant
> i've just updated repo elephant-unstable and ran tests with postmodern
> (i have few local changes but i don't think they make difference):
>
> Did 462 checks.
> Pass: 460 (99%)
> Skip: 1 ( 0%)
> Fail: 1 ( 0%)
That's great! :)
I must've missed something or unintentionally used a d
IE> Historically we've had problems with tests being non-idempotent. I
IE> usually wipe the dbs between runs to ensure that hidden interactions
IE> don't break test assumptions.
i have errors in a completely clean environment with a clean store:
Did 455 checks.
Pass: 449 (98%)
Skip:
Historically we've had problems with tests being non-idempotent. I
usually wipe the dbs between runs to ensure that hidden interactions
don't break test assumptions.
Ian
On Oct 28, 2008, at 9:23 AM, Alex Mizrahi wrote:
> LPP> The only major problem with it is that the Postmodern backend
> L
LPP> The only major problem with it is that the Postmodern backend
LPP> hasn't kept up with the schema evolution changes.
hm, what do you mean? i thought it works reasonably well, as there
are just a handful of glitches to left resolve, but i won't call that "a
major problem".
or am i missing
On Fri, 2008-10-24 at 09:11 +0200, Leslie P. Polzer wrote:
> The only major problem with it is that the Postmodern backend
> hasn't kept up with the schema evolution changes.
I did a bunch of work back in the spring to bring postmodern up-to-date,
and there were just a few failing tests at that t
> The most important thing is that this little community is making
> progress, for which we can thank Leslie and Alex and others for their
> code, as well as their willingness to try to make decisions about how
> the project should be managed.
I think it's important right now to get 092 out as an
Actually, I think it is necessary to have such conversations, and they
are bound to sound more heated in email than they would over coffee; but
we are a distributed team, and have to spend time in such communication
costs.
The most important thing is that this little community is making
progress,
> and what? i had some really painful 3-way merges in git, does that mean
> that git sucks too?
No, it rather means "the merge bothers me like hell, but at least I can
use a tool that doesn't get in my way."
> hash looks pretty unique for me
Make that "hash easily findable by the casual user"
LPP At least one revision from stable produces a non-trivial
??>>> merge in unstable.
??>>>
??>>> what does this mean?
LPP> It means I have to manually wade through at least two conflicting
LPP> revisions.
and what? i had some really painful 3-way merges in git, does that mean
th
Slightly off-topic but I want to defend poor little darcs..
On Thu, Oct 23, 2008 at 11:01 AM, Leslie P. Polzer
<[EMAIL PROTECTED]>wrote:
>
>
> The issue here isn't really "hg/git/ubercool-dvcs is better" but
> more like "darcs sucks".
>
> For example it drives me nuts that it doesn't give patches a
>> LPP> At least one revision from stable produces a non-trivial
>> merge in unstable.
>>
>>
>> what does this mean?
It means I have to manually wade through at least two conflicting
revisions.
>> why do you think mercurial would be free of problems? why not git?
>> what if next ye
I tend to agree with Alex. I don't think we need to optimize our use of
source control. I know nothing about Mercurial, having used only CVS,
subversion, and Darcs but I think getting 1.0 done should be our focus.
On Wed, 2008-10-22 at 21:58 +0300, Alex Mizrahi wrote:
> LPP> At least one
2008/10/22 Henrik Hjelte <[EMAIL PROTECTED]>
>
>
> On Wed, Oct 22, 2008 at 10:10 AM, Leslie P. Polzer <
> [EMAIL PROTECTED]> wrote:
>
>>
>> At least one revision from stable produces a non-trivial
>> merge in unstable.
>>
>> That would be a good opportunity to change revision control
>> systems.
>
LPP> At least one revision from stable produces a non-trivial
merge in unstable.
what does this mean?
LPP> If no one objects I'd do it with Mercurial and then upload
the resulting repository to Bitbucket.
why do you think mercurial would be free of problems? why not g
On Wed, Oct 22, 2008 at 10:10 AM, Leslie P. Polzer
<[EMAIL PROTECTED]>wrote:
>
> At least one revision from stable produces a non-trivial
> merge in unstable.
>
> That would be a good opportunity to change revision control
> systems.
>
> If no one objects I'd do it with Mercurial and then upload
>
At least one revision from stable produces a non-trivial
merge in unstable.
That would be a good opportunity to change revision control
systems.
If no one objects I'd do it with Mercurial and then upload
the resulting repository to Bitbucket.
Leslie
_
23 matches
Mail list logo
