[mailto:koushik@citrix.com]
Sent: donderdag 6 maart 2014 8:25
To: dev@cloudstack.apache.org
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
Message-
From: Koushik Das [mailto:koushik@citrix.com]
Sent: donderdag 6 maart 2014 8:25
To: dev@cloudstack.apache.org
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
...@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 time because
On Thu, Mar 6, 2014 at 11:28 AM, Alex Hitchins
alex.hitch...@shapeblue.com 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
] Checking in code that will break others' environments
On Thu, Mar 6, 2014 at 11:28 AM, Alex Hitchins alex.hitch...@shapeblue.com
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
: [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 their sql is a good first step, though.
On Thu, Mar 6
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 time
because i
would even want
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 code that will break others' environments
.
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 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.
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
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.
If we
+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,
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.
If we already have a policy around this, please let me know.
So, I fetched
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
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, 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,
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 mike.tutkow...@solidfire.com
wrote:
Yeah, I
17 matches
Mail list logo
