From the svn book (‘Postponing conflicts’ in the 1.7 version. Probably the main text before interactive resolution was added)
[[
For every conflicted file, Subversion places three extra unversioned files in your working copy:
filename.mine
This is the file as it existed in your working copy before you began the update process. It contains any local modifications you had made to the file up to that point. (If Subversion considers the file to be unmergeable, the .mine file isn't created, since it would be identical to the working file.)
filename.rOLDREV
This is the file as it existed in the BASE revision—that is, the unmodified revision of the file in your working copy before you began the update process—where OLDREV is that base revision number.
filename.rNEWREV
This is the file that your Subversion client just received from the server via the update of your working copy, where NEWREV corresponds to the revision number to which you were updating (HEAD, unless otherwise requested).
]]
Bert
Sent from Windows Mail
From: Daniel Shahaf
Sent: Thursday, March 19, 2015 8:04 AM
To: Bert Huijben
Cc: dev_at_subversion.apache.org
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 10:27:35 CET