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_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 09:26:10 CET