[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: On using svn for submitting patches

From: Marc Singer <elf_at_buici.com>
Date: 2003-10-10 17:38:29 CEST

On Thu, Oct 09, 2003 at 10:22:07PM -0500, Ben Collins-Sussman wrote:
> Marc Singer <elf@buici.com> writes:
>
> > I'm trying to understand how SVN can be used to prepare patches
> > against open development projects, e.g. svn. The conundrum is as
> > follows.
>
> This is not really an svn question, but a general question about open
> source version control methodology... no?

Well, I don't think so.

> You're describing what many people do. It's perfectly reasonable.
>
> For open-source projects, most submitted patches are one-shot deals.
> Somebody posts a patch to do exactly one thing. The submitter usually
> ends up resubmitting the patch a few times, because either a) people
> ask for corrections, or b) it falls 'out of date' with respect to the
> latest /trunk. There's always a small race-condition happening.

That's exactly where I would like source control to come to give us a
lift. And, thats why I think that this is really about svn and not
development in general. Branching, as described, is difficult in CVS.

> In some less common cases, a bugfix or feature requires a whole
> series of patches, each independently reviewable. Those are the
> situations in which we create a branch. When the work is done, the
> 'out-of-dateness' race condition still needs to be reconciled,
> usually by first merging "new" trunk changes into the branch, and
> then merging the branch back into trunk.

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.

trunk:

  for (i = 0; i < 10; ++i) {
    frob ();
  }

patch_1:

  for (i = 0; i < 10; ++i) {
    frob ();
    frob_another_day ();
  }

patch_2:

  for (i = 0; i < 10; ++i) {
    frob ();
    frob_another_day ();
  }
  clean_up_frobbing ();

Now, I realize that I made an error in patch_1 and I'd like the change
to propagate without affecting the contents of patch_2 which remains a
single line change.

patch_1:

  for (i = 0; i < 10; ++i) {
    frob ();
    frob_another_way ();
  }

And therefore...

patch_2:

  for (i = 0; i < 10; ++i) {
    frob ();
    frob_another_way ();
  }
  clean_up_frobbing ();

Does this make the question more clear?

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 10 17:39:14 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.