[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r1667280 - in /subversion/trunk/subversion: libsvn_wc/merge.c tests/cmdline/merge_tests.py

From: Bert Huijben <bert_at_qqmail.nl>
Date: Thu, 19 Mar 2015 07:08:40 +0000

This is not how Subversion worked until stsp changed this earlier this week. It worked this way for text conflicts, but not for binary conflicts.

What you ask is a bigger change, that in my opinion is better solved by storing the conflict details as checksums pointing into the binary blob/pristine store… as prepared wc.db was prepared for pre 1.7, but was never implemented yet. (Requires format dump… and checksum triggers in wc.db)


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
% svn update --non-interactive file.bin
C file.bin
% edit file.bin
% sha1sum file.bin
% 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?


Received on 2015-03-19 08:13:24 CET

This is an archived mail posted to the Subversion Dev mailing list.