Re: On using svn for submitting patches

> From: Marc Singer <elf@buici.com>

> How about this scenario. I'm working to add a refrob feature to
> package 'zoom'. Using SVN, I make a branch from the main line to work
> on the feature. This is a long line of development, so I work for a
> couple of days and submit a patch. The next day, I continue working
> and make more changes to the branch. The following day I submit
> another patch. Later that week, the first patch requires some work
> because the maintainer requests a different methodology. Trouble is,
> the requested change affects *both* of the submitted patches; and, the
> development point where the first patch was generated no longer exists
> as such.

> Let me draw a picture.

> +---------+-------------+------------+
> | trunk | patch_1 | patch_2 |
> +---------+-------------+------------+
> rev 8 rev 31 rev 67

> Ignoring for the time begin that the patches are being developed on a
> branch, what would be handy is if there is a way to make changes to
> patch_1 that automatically propagate to patch_2. I'd like to be able
> to edit what will be patch_1 as if it were inserted into the line of
> development.

Sussman is right that you might want to take a look at arch
(http://www.gnu.org/software/gnu-arch). It can help with a lot of the
automation, bookkeeping and conflict avoidence. If you learn to
"think archishly" it makess problems like this easier to reason about,
I think. Yadda yadda yadda.

But in svn land, I don't see why this particular problem would be all
that hard to solve:

Let's assume that you import and periodically update against the
project mainline as:

        /trunk/zoom

(So, that path is always the latest official sources.)

You start work on `refrob' by making a branch:

        cp /trunk/zoom@8 /branches/refrob-patch-1

and work on that branch until you hit your first milestone.

When it's time to submit a patch, submit:

        diff -r /trunk/zoom /branches/refrob-patch-1

Simultaneously to that:

        cp /branches/refrob-patch-1 /branches/refrob-patch-2

and continue your work on the new branch.

When you hit the next milestone, submit the patch:

        diff -r /branches/refrob-patch-1 /branches/refrob-patch-2

and start a new branch

        cp /branches/refrob-patch-2 /branches/refrob-patch-3

as the mainline evolves for independent reasons, you'll periodically
want to merge changes from /trunk/zoom to /branches/refrob-patch-1 and
from /branches/refrob-patch-1 to /branches/refrob-patch-2 (etc.)

When the feedback arrives, and you have to fix patch-1, do that work
on /branches/refrob-patch-1. Then merge those changes into
/branches/refrob-patch-2 and from there to patch-3. Finally resubmit
patches 1 and 2:

        diff -r /trunk/zoom /branches/refrob-patch-1
        diff -r /branches/refrob-patch-1 /branches/refrob-patch-2

When patch-1 is accepted, you can pretty much drop
/branches/refrob-patch-1 from the loop.

-t

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 10 20:07:59 2003