Stefan Sperling wrote on Thu, Mar 19, 2015 at 01:02:12 +0100: > On Wed, Mar 18, 2015 at 10:53:11PM +0100, Bert Huijben wrote: > > (Extending my original answer) > > > > Mine-full should just be implemented as a simple resolve without changing > > the file. The right 'mine' file is already in the right place on a conflict > > of a binary file. > > > > Creating a copy of a file, to allow replacing the original file with an > > identical copy is not that useful. > > > > > > For text conflicts we create a file with conflict markers, and make the > > original file available as mine. > > For binary files we can't (and don't) create such a file, so the file is > > untouched. > > > > Where does creating a copy help? > > > > Bert > > Implementing the "mine-full" option as a simple resolve sounds good. > Restoring the working file from a copy might be a bad idea indeed. > Perhaps the user did change the file after we copied it! > So we could store the file's working copy path as "mine".
Actually, as a user, if I do: % sha1sum file.bin 0xfoo % svn update --non-interactive file.bin C file.bin % edit file.bin % sha1sum file.bin 0xbar % svn resolve --accept=mine-full file.bin I'd expect the original version (0xfoo) to be installed. That's how it works for non-binary files. To accept the edited-post-conflict version (0xbar), I'd use accept=working. Note that mine-full irreversibly destroys the edited-post-conflict (0xbar) version of the file. Do people use mine-full and expect it to leave the 0xbar version untouched? Cheers, Daniel
