Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: softfail (nike.apache.org: transitioning domain of
 tiago@espinhas.net does not designate 209.85.215.172 as permitted sender)
Message-ID: <4FF549BB.3050806@espinhas.net>
Date: Thu, 05 Jul 2012 10:00:59 +0200
From: Tiago Espinha <tiago@espinhas.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
 rv:13.0) Gecko/20120614 Thunderbird/13.0.1
MIME-Version: 1.0
To: derby-dev@db.apache.org
Subject: Re: Managing multiple patches in eclipse
References: 
 <CAHuvxeU5E2c0oDQG8hKG1B=UgKtS0MgjBapdKgqirgdfus0Ltg@mail.gmail.com>
 <4FF4C27B.6080106@sbcglobal.net>
In-Reply-To: <4FF4C27B.6080106@sbcglobal.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On 7/5/12 12:23 AM, Katherine Marsden wrote:
> On 7/3/2012 6:26 PM, siddharth srivastava wrote:
>> Hi
>>
>> While improvising code coverage, I made a lot of changes in different
>> files. Now the changes in each file is a patch in itself.
>> So my question was, how do you create/manage diff for multiple issues
>> simultaneously.
>> The process I have been following now was to make change, create diff,
>> revert back and again do the same for next patch.
>> But now since I have 8-10 patches, is there a sane way of doing this ?
>>
> One option is to have multiple work spaces, just svn co to a different
> location if you have enough disk space.  If your changes are in
> distinct files, you can have them all in one work space and create
> individual patches with svn diff  <filename> .  I've done that with
> two or three, never eight or ten.  Probably that is a sign that your
> patches are backing up.  Do you have a list that needs review and commit?
>
> Thanks
>
> Kathey
>
>
>
>
Two comments I'd like to make:
- While I'm a great fan and advocate for Git, I would really stay away
from it unless you have previous experience. The terminology is, at
first, extremely confusing for SVN users and you will (trust me, you
will) lose tremendous amounts of time and possibly code while you get
the hang of it. I speak on own experience and on what I see from other
people. After you get the hang of it, it's perfect, but I would stick to
svn for now.

- As for dealing with this kind of thing, pen and paper works best in my
experience. Just sort out which files should be patched for each issue,
create a big patch and then slice your patch file into smaller patches
that just fix that one specific issue.

This has the potential to create all kinds of trouble (e.g. the patches
interact... the tests only pass when the two patches are applied, etc)
and it also requires some care when you are dealing with the patch
slicing but all in all, I still found it to be the easiest and fastest
approach for me.

Tiago