Why are you quoting the svnbook definition of .mine .rOLD .rNEW to me? I know what they are.
If your point was the ".mine file isn't created because it would be identical to the working file", then, again: I don't care about the implementation right now. I don't care whether the contents is stored in the .mine file, in the pristine store, or anywhere else. I care about the semantics of 'svn resolve' from a user's perspective. Daniel Bert Huijben wrote on Thu, Mar 19, 2015 at 07:27:54 +0000: > 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@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
