[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: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2003-10-10 05:22:07 CEST

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?

> 1) Public development proceeds along a path. There are asynchronous
> updates to the main line of code.
> 2) Local development proceeds on several fronts. We may be fixing
> bugs as well as developing new features.
> 3) Patches submitted for inclusion in the public archive may require
> changes before being accepted.
> 4) Pending patches may be necessary for development on several
> fronts. For example, a bug fix may found and submitted while
> working on a new feature and before that feature is ready for
> submission.

Yes, this pretty much describes all open source projects.

> My first approximation is to let the trunk reflect the published
> development process with a branch for each line of development. For
> example, a bug fix would be pursued on a branch of its own. Likewise,
> new features are developed in a branch per submittable chunk.

Yes, this is a very common methodology. It's not specific to any
version control system.

> The questions are
> Is this a reasonable method for developing 'patches'?
> Is there something better?

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.

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.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 10 05:24: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.