On Mon, Jan 28, 2019 at 09:24:41PM +0100, bonsma wrote:
> Hi all,
> When we upgraded from Subversion 1.8.17 to Subversion 1.9.7 we
> noticed a change in behaviour of svn update. This happens when the
> update pulls in a change that deletes a directory while this directory
> contains one or more unversioned files in your local working copy.
> What used to happen with svn 1.8 was the following:
> - The versioned files inside the removed directory are removed
> - Any unversioned files remain present
> What now happens with svn 1.9 is:
> - A tree conflict is signalled with the following details:
> > local dir edit, incoming dir delete or move upon update
> This subsequently requires action by the developer to resolve the
> conflict before he can use the working copy again. Furthermore, when
> resolved incorrectly, the deleted directory may (unintentially) be
> added again.
> In our archive we have the build generate files throughout the
> working copy (obj folders, files generated from template, output
> folders per sub-codebase, etc). We also regularly delete directories
> as part of refactoring, so the tree conflicts occur quite frequently
> and are considered an inconvenience by our developers.
> So we would like to know, is the new behaviour intentional or is it
> an accidental side-effect of another change? We did not see this
> change documented in the release notes.
> Kind regards,
Yes, this behaviour is expected in SVN 1.9. Tree conflict detection was made
more aggressive in anticipation of the conflict resolver released in SVN 1.10
and later. This conflict resolver depends on conflict markers to operate.
The basic idea is that developers should be able to resolve tree conflicts
in a semi-automated way by picking an item from a conflict resolution menu.
There are many possible tree conflicts and corresponding resolutions, and
implementing many resolution strategies takes a lot of time and effort. The
situation is improving with each release of SVN but it is not yet perfect.
As for your specific case, it unfortunately looks like there is currently no
way to make the resolver preserve the unversioned files you want to preserve.
As you point out, SVN 1.9 and onwards will re-add the directory by default.
The intention here is to preserve any local changes in this directory by
default when the user hits the 'mark resolved' button without really knowing
what this button will do. We don't want people to complain about SVN deleting
their uncommitted changes. Of course, if "local changes" are composed only of
unversioned items, keeping the directory under version control makes no sense.
I will look at making 'svn update' detect this case if possible, or will add
a resolver menu option which handles this conflict in a way that preserves
unversioned items on disk.
Please note that releases older than SVN 1.10 are no longer supported by
this community. The behaviour of SVN 1.9 won't ever be changed.
Going forward, please use SVN 1.11.x releases for resolving tree conflicts.
That line of releases contains the most up-to-date resolver implementation and
is being fed with improvements and new conflict resolution options over time.
Some improvements are also being ported back to 1.10.x releases.
Please refer to our CHANGES file for notes about conflict resolver
improvements in current and future releases:
Received on 2019-01-29 10:48:43 CET