a script that rebuilt my
> testbed by replaying the API calls I made to set it up in the first place.
> >
> > Is this a solution you've considered for your dev environment?
> >
> > DL
> >
> >> -----Original Message-
> >> From: Daan Hooglan
e.
>
> Is this a solution you've considered for your dev environment?
>
> DL
>
>> -Original Message-
>> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
>> Sent: 06 March 2014 12:50
>> To: dev
>> Cc: Daan Hoogland
>> Subject: Re: [DISCUSS]
up in the first place.
Is this a solution you've considered for your dev environment?
DL
> -Original Message-
> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
> Sent: 06 March 2014 12:50
> To: dev
> Cc: Daan Hoogland
> Subject: Re: [DISCUSS] Checking in cod
iginal Message-
>> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
>> Sent: 06 March 2014 09:53
>> To: dev
>> Cc: Daan Hoogland
>> Subject: Re: [DISCUSS] Checking in code that will break others' environments
>>
>> I totally agree with the inc
t A, and afterwards upgrade it again to the point they ran
> statement B.
> > The same principle could also be applied to the Java classes that do data
> migration, but maybe there it might be a bit more involved.
> >
> > Cheers,
> > Miguel
> >
> > -Original Messa
] Checking in code that will break others' environments
On Thu, Mar 6, 2014 at 11:28 AM, Alex Hitchins
wrote:
> I agree too with this approach. One thing I'm not too familiar with is how
> the current SQL versioning handled? I know of the schema-xxtoxx sql files but
> not so much ho
On Thu, Mar 6, 2014 at 11:28 AM, Alex Hitchins
wrote:
> I agree too with this approach. One thing I'm not too familiar with is how
> the current SQL versioning handled? I know of the schema-xxtoxx sql files but
> not so much how this are arranged.
>
H Alex,
The present upgrades are on a per re
hitch...@shapeblue.com
-Original Message-
From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
Sent: 06 March 2014 09:53
To: dev
Cc: Daan Hoogland
Subject: Re: [DISCUSS] Checking in code that will break others' environments
I totally agree with the incremental approach. I am a fascist at ti
re it might be a bit more involved.
>
> Cheers,
> Miguel
>
> -Original Message-
> From: Koushik Das [mailto:koushik....@citrix.com]
> Sent: donderdag 6 maart 2014 8:25
> To:
> Subject: Re: [DISCUSS] Checking in code that will break others' environments
>
>
k Das [mailto:koushik@citrix.com]
Sent: donderdag 6 maart 2014 8:25
To:
Subject: Re: [DISCUSS] Checking in code that will break others' environments
Before doing a git pull, I generally check the sql schema changes and run the
delta manually on my existing setup. In most of the cases that wo
Before doing a git pull, I generally check the sql schema changes and run the
delta manually on my existing setup. In most of the cases that works for me
without having to redeploy the db.
-Koushik
On 06-Mar-2014, at 11:43 AM, Mike Tutkowski
wrote:
> Yeah, I definitely just meant a "heads up
Yeah, I definitely just meant a "heads up" during development if you are
going to change something that will break other people's environments who
update. If these people know in advance, they may choose to postpone an
update until they are at a better point.
On Wed, Mar 5, 2014 at 11:01 PM, Raja
Across versions db migration is taken care. I think this is bound to occur
while working on a release, if multiple people work on the same branch with
different work-in-progress features.
Could we move to flyway or liquibase which can take care of db versioning and
migration?
~Rajani
On
Yeah, in this case, I'm not referring to erroneous code that breaks a
person's environment (since hopefully the person wouldn't have knowingly
checked in such code), but rather, say, DB-type changes that improve the
system, but break current setups.
Just a heads-up e-mail with some easily identifi
I see two recent SQL-related updates:
f291951990fbf0c51c2e9aa95d246d73e8abde8b
339c4f4c3fb4f50e58b780893b16be192f985d82
On Wed, Mar 5, 2014 at 1:23 PM, Sudha Ponnaganti <
sudha.ponnaga...@citrix.com> wrote:
> +1 esp changes in DB area should be notified.
> DB changes should be frozen couple of
+1 to this.
Having the build suddenly break due to a git pull has been very annoying!
I usually end up searching through the commit log and doing a resets
until I find a commit where it works. Then waiting awhile until I do a
git pull again and hoping the code was fixed.
On 5 March 2014 20:19, Mi
+1 esp changes in DB area should be notified.
DB changes should be frozen couple of weeks before RC so QA would get time to
run through tests - otherwise we would be going in circles.
BTW do you have commit id for this particular check in
Thanks
/Sudha
-Original Message-
From: Mike Tu
17 matches
Mail list logo
