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

Re: Commiting, tree conflicts and keep-local

From: Stefan Sperling <stsp_at_elego.de>
Date: Wed, 25 Aug 2010 21:09:42 +0200

On Wed, Aug 25, 2010 at 05:00:09PM +0100, Julian Foad wrote:
> On Tue, 2010-08-24, Julian Foad wrote:
> [...]
> > What should happen?
> > -------------------
> >
> > I think the required changes are:
> >
> > * Commit should unconditionally bail out if there are any conflicts
> > inside a node being committed. No more testing the 'keep_local' flag at
> > this stage.
> I'm sure that's the behaviour we should have. The only thing I don't
> understand is why Neels changed harvest_committables() to ignore
> conflicts if 'keep_local' is set in r878027. That commit was about
> fixing some problems with keep_local, but it's not clear to me why this
> particular change was made. I assumed it was to preserve some 1.6.x
> behaviour, but I've just tested with a 1.6.x branch build and it doesn't
> allow the commit.
> I'm removing that condition, so the commit will fail if there are
> unresolved conflicts, even inside a directory scheduled for delete.
> This doesn't cause any test failures except tree_conflicts_tests 17
> (which is specifically about this behaviour) and it brings the commit
> code back into line with 1.6.x in which
> bail_on_tree_conflicted_children() was called unconditionally.
> I've committed this in 989189.
> If Neels or anyone can confirm this diagnosis, that would be great.

I guess that auto-resolving tree conflicts inside a locally deleted
subtree was intended as a user convenience.
But requiring an explicit 'svn resolve' invocation to resolve the conflict
before commit is in line with the general behaviour of Subversion, so I think
your change (reverting Neels changes) is sound.

Received on 2010-08-25 21:10:49 CEST

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.