You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Ben Collins-Sussman <su...@collab.net> on 2004/04/16 18:22:02 UTC
Merging r9254
We're starting to get to the point where a lot of backported changes
don't apply cleanly to the 1.0.x branch anymore. In IRC, breser and I
were thinking that maybe it's time to start voting on backported
patches, rather than revnums.
For example, I'd really like to get this into 1.0.2 (because we have
other similar changes in 1.0.2 already), but I've not been following the
'shared wc' thread carefully. I get a conflict when merging this teensy
change:
* r9254
Fix for updates to svn:executable files in shared working copies.
Justification: Hard to use svn:executable in shared working copies
without it.
Votes:
+1: philip, dlr, breser
Philip, can you try doing the merge? You're qualified to understand the
conflict, and I'm not.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merging r9254
Posted by Ben Reser <be...@reser.org>.
On Fri, Apr 16, 2004 at 01:22:02PM -0500, Ben Collins-Sussman wrote:
> We're starting to get to the point where a lot of backported changes
> don't apply cleanly to the 1.0.x branch anymore. In IRC, breser and I
> were thinking that maybe it's time to start voting on backported
> patches, rather than revnums.
>
> For example, I'd really like to get this into 1.0.2 (because we have
> other similar changes in 1.0.2 already), but I've not been following the
> 'shared wc' thread carefully. I get a conflict when merging this teensy
> change:
>
> * r9254
> Fix for updates to svn:executable files in shared working copies.
> Justification: Hard to use svn:executable in shared working copies
> without it.
> Votes:
> +1: philip, dlr, breser
>
> Philip, can you try doing the merge? You're qualified to understand the
> conflict, and I'm not.
I can do this merge. Philip has said already he's not interested in
r9254. So I'll deal with this conflict.
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merging r9254
Posted by Ben Reser <be...@reser.org>.
On Fri, Apr 16, 2004 at 02:17:27PM -0500, kfogel@collab.net wrote:
> Ben Collins-Sussman <su...@collab.net> writes:
> > We're starting to get to the point where a lot of backported changes
> > don't apply cleanly to the 1.0.x branch anymore. In IRC, breser and I
> > were thinking that maybe it's time to start voting on backported
> > patches, rather than revnums.
>
> For strictly textual conflicts, I don't think an extra patch stage is
> needed. For semantic dependencies, well, that's a different
> question...
>
> Is the latter happening a lot?
We're starting to see more merges that contain conflicts that (at least
IMHO take a bit of thought to wrap your head around). Take r9084.
There were two conflicts.
One for a change that was done in r9084 to revert using a subpool, but
1.0.x wasn't using a subpool.
Another for a change that changed a line that didn't exist in 1.0.x and
was actually in an entirely different place in the code, which also had
to be changed from using a subpool.
It'd be much easier on the merge end if the person familiar with the
code was looking at these conflicts. Because if I do the merges I have
to wrap my head around the various changes on trunk and the branch to
figure out what really needs to be merged.
They're not terribly complex to resolve. But I'm a bit paranoid about
making a mistake in this case. Whereas, presumable the people working
on the code understand the history of trunk and already know why the
conflict occured.
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merging r9254
Posted by Branko Čibej <br...@xbc.nu>.
kfogel@collab.net wrote:
>Ben Reser <be...@reser.org> writes:
>
>
>>Ohh yeah one other thing I forgot. We're voting on changes based upon
>>the change on trunk. Problem is people look at the diff on trunk and
>>then vote on that. Then when we go to merge we run into situations
>>where other changes that were necessary didn't get nominated, which
>>means we're looking for people to review them at the last minute. This
>>can't be good for quality.
>>
>>
>
>Wow, that's a good point.
>
><musing out loud...>
>
>We don't want to waste time generating patches (and filing issues to
>hold them) that don't really differ from the corresponding revisions.
>
>Maybe it would be good to divide the release process into stages, even
>if it means releases take a bit longer:
>
> 1. Nomination and voting period.
> 2. Trial merges.
> 3. Creation of patches where necessary, as revealed by step 2.
> 4. Last voting round, includes the patches (which have issue numbers).
>
>To ensure termination, have a policy that new nominations which come
>in after stage 1 don't have to go into this release, they can go into
>the next one.
>
>
We could also make things simpler by creating a 1.0.x-staging branch
(from 1.0.x, of course). Anyone who has a candidate change merges it
from trunk to 1.0.x-staging and proposes _that_ commit. Those changes
should always apply cleanly to 1.0.x.
After a release, we merge form 1.0.x back to the staging branch.
Candidates that got punted to a later patch remain there, those that got
vetoed can be removed from the staging branch.
This keeps patch candidates in the repository where they belong, instead
of scattered throughout the mailing list, and has the advantage that
potentially conflicting changes can be tested together before they go to
the release branch, keeping 1.0.x as clean as possible.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merging r9254
Posted by kf...@collab.net.
Ben Reser <be...@reser.org> writes:
> Ohh yeah one other thing I forgot. We're voting on changes based upon
> the change on trunk. Problem is people look at the diff on trunk and
> then vote on that. Then when we go to merge we run into situations
> where other changes that were necessary didn't get nominated, which
> means we're looking for people to review them at the last minute. This
> can't be good for quality.
Wow, that's a good point.
<musing out loud...>
We don't want to waste time generating patches (and filing issues to
hold them) that don't really differ from the corresponding revisions.
Maybe it would be good to divide the release process into stages, even
if it means releases take a bit longer:
1. Nomination and voting period.
2. Trial merges.
3. Creation of patches where necessary, as revealed by step 2.
4. Last voting round, includes the patches (which have issue numbers).
To ensure termination, have a policy that new nominations which come
in after stage 1 don't have to go into this release, they can go into
the next one.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merging r9254
Posted by Ben Reser <be...@reser.org>.
On Fri, Apr 16, 2004 at 02:17:27PM -0500, kfogel@collab.net wrote:
> Ben Collins-Sussman <su...@collab.net> writes:
> > We're starting to get to the point where a lot of backported changes
> > don't apply cleanly to the 1.0.x branch anymore. In IRC, breser and I
> > were thinking that maybe it's time to start voting on backported
> > patches, rather than revnums.
>
> For strictly textual conflicts, I don't think an extra patch stage is
> needed. For semantic dependencies, well, that's a different
> question...
Ohh yeah one other thing I forgot. We're voting on changes based upon
the change on trunk. Problem is people look at the diff on trunk and
then vote on that. Then when we go to merge we run into situations
where other changes that were necessary didn't get nominated, which
means we're looking for people to review them at the last minute. This
can't be good for quality.
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merging r9254
Posted by kf...@collab.net.
Ben Collins-Sussman <su...@collab.net> writes:
> We're starting to get to the point where a lot of backported changes
> don't apply cleanly to the 1.0.x branch anymore. In IRC, breser and I
> were thinking that maybe it's time to start voting on backported
> patches, rather than revnums.
For strictly textual conflicts, I don't think an extra patch stage is
needed. For semantic dependencies, well, that's a different
question...
Is the latter happening a lot?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org