[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Merging r9254

From: Ben Reser <ben_at_reser.org>
Date: 2004-04-16 22:52:51 CEST

On Fri, Apr 16, 2004 at 02:17:27PM -0500, kfogel@collab.net wrote:
> Ben Collins-Sussman <sussman@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 <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
Received on Fri Apr 16 22:53:12 2004

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.