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