> -----Original Message-----
> From: MARTIN PHILIP [mailto:codematters_at_ntlworld.com] On Behalf Of
> Philip Martin
> Sent: woensdag 2 januari 2013 19:07
> To: Julian Foad
> Cc: C. Michael Pilato; Stefan Sperling; Ben Reser; Subversion Development
> Subject: Re: 1.8 Progress
>
> Philip Martin <philip.martin_at_wandisco.com> writes:
>
> > I still think we may get something working by the end of the year. The
> > simple cases will work and should be useful. The more complex cases
> > should also work to some extent, but it's possible that some subsequent
> > tree-conflicts that should be detected while resolving the first
> > tree-conflict may get missed.
>
> This now works to a certain extent. When an update attempts to apply
> changes to a moved tree it causes a tree-conflict on the move source
> just like 1.7. When resolving the tree-conflict the user can choose to
> apply the changes to the move destination and this now updates the NODES
> rows for the move destination and merges the changes in the working
> files. This may in turn generate tree-conflicts in the move destination
> for nested moves, deletes, obstructions. For nested moves the
> tree-conflict can also be resolved by applying the changes to the move
> destination.
>
> Things that need more work:
>
> - tests.
>
> - handling deleting files/dirs from the working files, at present they
> are left unversioned.
>
> - 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.
>
> - switch can cause the tree-conflicts on the move source, at present
> the new code hard-codes 'update'.
>
> - more tests (again).
Bert
Received on 2013-01-02 20:07:51 CET