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