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
Received on 2015-03-19 08:07:26 CET