You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Marc Singer <el...@buici.com> on 2003/10/09 23:28:13 UTC
On using svn for submitting patches
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.
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.
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.
The questions are
Is this a reasonable method for developing 'patches'?
Is there something better?
Cheers.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: On using svn for submitting patches
Posted by Ben Collins-Sussman <su...@collab.net>.
Marc Singer <el...@buici.com> writes:
> 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.
"Propogate"? What does that mean?
In subversion, patches are not first-class objects; trees are. You
have a branch-tree which represents the results of a long line of
changes. But there's no way to talk about cause and effect: "hey, I
want to change patch 1, which therefore has a ripple effect on
subsequent patches." There are no 'patch objects' to manage.
Instead, you just keep making changes to your branch, so that the
*result* (i.e. HEAD tree on your branch) looks as *if* patch 1 had
been changed way back in time.
It sounds to me like you're talking about the arbitrary composition of
patches, where each patch ("changeset") exists as an 1st-class object
with its own life. You want to build arbitrary trees by composing
arbitrary patches; the trees are the derived objects.
It sounds like you want 'arch'. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: On using svn for submitting patches
Posted by Tom Lord <lo...@emf.net>.
> From: Marc Singer <el...@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
Re: On using svn for submitting patches
Posted by Marc Singer <el...@buici.com>.
On Thu, Oct 09, 2003 at 10:22:07PM -0500, Ben Collins-Sussman wrote:
> Marc Singer <el...@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
Re: On using svn for submitting patches
Posted by Marc Singer <el...@buici.com>.
On Thu, Oct 09, 2003 at 10:22:07PM -0500, Ben Collins-Sussman wrote:
> Marc Singer <el...@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
Re: On using svn for submitting patches
Posted by Ben Collins-Sussman <su...@collab.net>.
Marc Singer <el...@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
Re: On using svn for submitting patches
Posted by kf...@collab.net.
Marc Singer <el...@buici.com> writes:
> 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.
>
> The questions are
>
> Is this a reasonable method for developing 'patches'?
> Is there something better?
I'm not sure what you concretely mean by "developing 'patches'", but
this is a reasonable way to handle multiple related lines of
development. When a bug is fixed on one line, and is known to apply
to others too, use 'svn merge' to port it across. Try to keep
experimental branches short-lived: when the experiment is done, merge
the changes into some more permanent line and remove the branch.
That's my $0.02, YMMV :-).
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: On using svn for submitting patches
Posted by John Peacock <jp...@rowman.com>.
Michael Wood wrote:
> Shouldn't that be:
> [...]
> * merge from trunk@HEAD (where HEAD == X) one last time
> * diff from HEAD of branch to trunk@X
>
> Otherwise there's a race. Something could change on trunk between the
> last two steps which would cause you to revert stuff you shouldn't.
>
> (This is all assuming trunk changes automatically, which is probably
> wrong. I suppose you probably run apc2svn to update the stuff in
> trunk manually?)
>
You are right; in my case HEAD on trunk will not change except during the
automatic update at 1am EST (if I'm up programming that late, I deserve the
problems it will cause;~). But for absolute consistency purposes, I should do
trunk@X...
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: On using svn for submitting patches
Posted by Michael Wood <mw...@its.uct.ac.za>.
On Fri, Oct 10, 2003 at 09:44:50AM -0400, John Peacock wrote:
[sni]
> I create a branch (or several) for my development work, to which I
> merge from the trunk occasionally. When I am ready to submit a patch,
> I make sure I merge from the trunk one last time (to test that the
> patch is not going to break anything), then I do a diff from the HEAD
> of the branch to the HEAD of the trunk, and this is what should apply.
[snip]
Shouldn't that be:
[...]
* merge from trunk@HEAD (where HEAD == X) one last time
* diff from HEAD of branch to trunk@X
Otherwise there's a race. Something could change on trunk between the
last two steps which would cause you to revert stuff you shouldn't.
(This is all assuming trunk changes automatically, which is probably
wrong. I suppose you probably run apc2svn to update the stuff in
trunk manually?)
--
Michael Wood <mw...@its.uct.ac.za>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: On using svn for submitting patches
Posted by John Peacock <jp...@rowman.com>.
Marc Singer wrote:
> 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.
To pile on to the other responses, yes, this is exactly the way to do it. I
have been working on several major enhancements to Perl (dealing with version
objects). Perl is currently managed in Perforce, so I have a custom repository
of Perl (using the amazing apc2svn) in subversion.
I create a branch (or several) for my development work, to which I merge from
the trunk occasionally. When I am ready to submit a patch, I make sure I merge
from the trunk one last time (to test that the patch is not going to break
anything), then I do a diff from the HEAD of the branch to the HEAD of the
trunk, and this is what should apply.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org