Return-Path: Delivered-To: apmail-ibatis-dev-archive@www.apache.org Received: (qmail 17531 invoked from network); 21 Feb 2010 15:53:54 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 21 Feb 2010 15:53:54 -0000 Received: (qmail 48879 invoked by uid 500); 21 Feb 2010 15:53:54 -0000 Delivered-To: apmail-ibatis-dev-archive@ibatis.apache.org Received: (qmail 48841 invoked by uid 500); 21 Feb 2010 15:53:53 -0000 Mailing-List: contact dev-help@ibatis.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@ibatis.apache.org Delivered-To: mailing list dev@ibatis.apache.org Received: (qmail 48833 invoked by uid 99); 21 Feb 2010 15:53:53 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 21 Feb 2010 15:53:53 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of clinton.begin@gmail.com designates 74.125.92.144 as permitted sender) Received: from [74.125.92.144] (HELO qw-out-1920.google.com) (74.125.92.144) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 21 Feb 2010 15:53:47 +0000 Received: by qw-out-1920.google.com with SMTP id 5so263852qwc.60 for ; Sun, 21 Feb 2010 07:53:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:content-type; bh=Hdws+aK6rhxwcdd7XtA+7uVTihiqeHqL4RD6rCM8ChM=; b=k/Eg4ny1JgwaFgHR5dYsWoO4UdLkixZEKCJJ6iMZBaowSNLGc+wpDVdONGZe25cuiE fT1ZUf8PEWVKRYddYZGdBPmGRkNtL6gDXfHUOD5Ktt6N7Poa+Tj2f0TMJs/uUog1oJbk YClvKC/KAox/GEJeawDug4bWtaAY2eA8qYVf4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=Kfj0D/5SXuPN5AhTuTsY8N/ZApnIXsW3trO7IW8kFrzZ/+7Zvllkfk+pDculAKjLK7 9HC2nxdVKN1fIxCm5qqvfxXkV1nqapFtW2wD0TupzzEY4zzbuKsVCOmHlBsgaQUHmxl1 WhP+zJS1cugNSL2RJLrhjJEUZs8mk9BaZn+90= MIME-Version: 1.0 Received: by 10.224.95.13 with SMTP id b13mr1678706qan.64.1266767606210; Sun, 21 Feb 2010 07:53:26 -0800 (PST) In-Reply-To: <81cfe9551002210510p594130f3tfe783e50cc232f74@mail.gmail.com> References: <81cfe9551002210510p594130f3tfe783e50cc232f74@mail.gmail.com> From: Clinton Begin Date: Sun, 21 Feb 2010 08:53:06 -0700 Message-ID: <16178eb11002210753y4cff36besbf01ed2fc481e6c7@mail.gmail.com> Subject: Re: Migrator: system properties via command line. To: dev@ibatis.apache.org Content-Type: multipart/alternative; boundary=0016360e3b742e629504801e512b --0016360e3b742e629504801e512b Content-Type: text/plain; charset=ISO-8859-1 This was the purpose behind the environments. Each developer could have their own environment file, perhaps by their username. You could ignore such files from your version control system. This way, no matter how many properties differ, you can just specify the environment like: migrate --env=cbegin status Which is shorter than even one of your properties above. Clinton On Sun, Feb 21, 2010 at 6:10 AM, Marco Speranza wrote: > Hi all guys, I'm using migrator and I think that is a beautiful tool. In my > company we use migrator into a team of 10 person, each developer has its own > database. Into scm we have committed only two files: prod.properties (for > production environment) and developer.properties (for dev environment) So > each developer have to modify the developer.properties file with you > personal information. My little idea is this: add a new migrator command > line argument that overwrites "on the fly" any properties like this: > > migrate -Dusername=bob -Dpassword=superSecret -DotherProp=value up > > what do you think about this? If you think it's a good idea, I'd like to > implement this features. > > thank a lot. > > best regards > -- > Marco Speranza > --0016360e3b742e629504801e512b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This was the purpose behind the environments.=A0 Each developer could have = their own environment file, perhaps by their username. You could ignore suc= h files from your version control system.=A0

This way, no matter ho= w many properties differ, you can just specify the environment like:

migrate --env=3Dcbegin status

Which is shorter than even one of = your properties above.=A0

Clinton

On Sun, Feb 21, 2010 at 6:10 AM, Marco Speranza <marco.speranza79@gmail.com>= ; wrote:
Hi all guys, I'm using migrator and I think that is a beautiful tool. In my company we use migrator into a team of 10 person, each developer has = its own database. Into scm we have committed only two files: prod.properti= es (for production environment) and developer.properties (for dev environme= nt) So each developer have to modify the developer.properties file with you per= sonal information.=20 My little idea is this: add a new migrator command line argument that overw= rites "on the fly" any properties like this:

migrate -Dusername=3Dbob -Dpassword=3DsuperSecret = -DotherProp=3Dvalue up

what do you think abou= t this? If you think it's a good idea, I'd like to implement this f= eatures.

thank a lot.=A0

best regards
--
Marco Speranza <marco.speranza79@gmail.com>

--0016360e3b742e629504801e512b--