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
d
> Subject: Re: [DISCUSS] Checking in code that will break others' environments
>
> I totally agree with the incremental approach. I am a fascist at time because
> i
> would even want people to add downgrade scripts to any db change they
> make. Having them not adjust
] 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
solidfire.com]
> Sent: Wednesday, March 05, 2014 12:19 PM
> To: dev@cloudstack.apache.org
> Subject: [DISCUSS] Checking in code that will break others' environments
>
> Hi,
>
> I encountered a bit of a problem this morning and thought I would bring it
> up for discuss
+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
Tutkowski [mailto:mike.tutkow...@solidfire.com]
Sent: Wednesday, March 05, 2014 12:19 PM
To: dev@cloudstack.apache.org
Subject: [DISCUSS] Checking in code that will break others' environments
Hi,
I encountered a bit of a problem this morning and thought I would bring it up
for discussion.
Hi,
I encountered a bit of a problem this morning and thought I would bring it
up for discussion.
If we already have a policy around this, please let me know.
So, I fetched the latest and rebased my local 4.4 development branch on top
of master. This all went just fine.
When I rebuilt and re-st
18 matches
Mail list logo
