On Sun, Nov 20, 2022 at 10:42 PM Daniel Sahlberg < daniel.l.sahlb...@gmail.com> wrote:
> Den sön 20 nov. 2022 kl 19:16 skrev Pavel Lyalyakin via dev < > dev@subversion.apache.org>: > >> Hello, >> >> As reported in this users@ thread[1][2], it appears that running `svn >> update` can silently remove unversioned files in the working copy when >> automatically resolving a tree conflict. Note that when I run `svn update` >> with the `--accept postpone` option, the unversioned file remains in the >> working copy. >> >> Should I create a ticket in Jira? I have a reproduction script for >> Windows and macOS. >> > > I think this qualifies for a ticket! > > >> I guess that the macOS script also works on Linux. >> > > The script seems to work under Linux (at least Ubuntu 22.04 running on > WSL). As far as I understand, the issue is the same: unversionedfile.txt is > missing after the rename). > > [[[ > daniel@DESKTOP-DT42993:~/marcel-bug-report/working-copy-one$ svn resolve > Searching tree conflict details for 'RenamedDir/myfile.txt' in repository: > Checking r2... done > Tree conflict on 'RenamedDir/myfile.txt': > A new file appeared during update to r3; it was added by daniel in r2. > An unversioned file was found in the working copy. > Select: (p) Postpone, (r) Mark as resolved, (m) Merge the files, (h) Help, > (q) Quit resolution: > ]]] > > Note that the error message mention "[a]n unversioned file", however the > conflict is on the versioned file. > > Kind regards, > Daniel > I've just created SVN-4910: https://issues.apache.org/jira/browse/SVN-4910 Thank you! -- With best regards, Pavel Lyalyakin VisualSVN Team
