> -----Original Message-----
> From: MARTIN PHILIP [mailto:codematters_at_ntlworld.com] On Behalf Of
> Philip Martin
> Sent: vrijdag 4 januari 2013 16:07
> To: Bert Huijben
> Cc: 'Julian Foad'; Michael Pilato; 'Stefan Sperling'; 'Ben Reser';
'Subversion
> Development'
> Subject: Re: 1.8 Progress
>
> "Bert Huijben" <bert_at_qqmail.nl> writes:
>
> >> -----Original Message-----
> >> From: MARTIN PHILIP [mailto:codematters_at_ntlworld.com] On Behalf Of
> >>
> >> - handle an update that makes no text/property/tree changes in the
> >> move source, probably by creating a tree-conflict during the
> >> post-drive revision bump.
> >
> > So, create a tree conflict on *every* update?
> >
> > If there is no change I would just bump the copyfrom revision. Making
> every
> > update of a working copy after a move a tree conflict is not what I
would
> > expect as a Subversion user.
> >
> > I wouldn't call that a releasable state for 1.8.
>
> Looking at this a bit more I see that the post-drive changes are made
> within a single transaction so most updates don't need a tree-conflict,
> it can be resolved automatically. The only time a tree-conflict might
> be needed is on the rare occasions that the update results in a
> mixed-revision move source.
And in this case I fully agree that we should introduce a tree conflict and
a path to recover from this problem.
(Probably fix the conflict/obstruction that made the update skip the nodes,
followed by running update again)
But there shouldn't be many scenarios where this happens.
As far as I can tell a moved away node can only be obstructed by an
obstructing working copy. Even conflicts on the move-from-root should allow
BASE being updated. (In all other scenarios the node is shadowed and we
still update BASE)
Hmm... and even then, in the post update bump we handle everything in-db, so
we don't check for obstructing working copies because we use wcroot, relpath
for processing.
So, which skip scenario would then remain?
Bert
Received on 2013-01-04 16:49:10 CET