subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bert Huijben" <b...@qqmail.nl>
Subject RE: svn commit: r1667280 - in /subversion/trunk/subversion: libsvn_wc/merge.c tests/cmdline/merge_tests.py
Date Wed, 18 Mar 2015 21:53:11 GMT


> -----Original Message-----
> From: Branko ─îibej [mailto:brane@wandisco.com]
> Sent: woensdag 18 maart 2015 02:00
> To: dev@subversion.apache.org
> Subject: Re: svn commit: r1667280 - in /subversion/trunk/subversion:
> libsvn_wc/merge.c tests/cmdline/merge_tests.py
> 
> On 17.03.2015 22:53, Stefan Sperling wrote:
> > On Tue, Mar 17, 2015 at 10:11:28PM +0100, Bert Huijben wrote:
> >>
> >>> -----Original Message-----
> >>> From: stsp@apache.org [mailto:stsp@apache.org]
> >>> Sent: dinsdag 17 maart 2015 13:05
> >>> To: commits@subversion.apache.org
> >>> Subject: svn commit: r1667280 - in /subversion/trunk/subversion:
> >>> libsvn_wc/merge.c tests/cmdline/merge_tests.py
> >>>
> >>> Author: stsp
> >>> Date: Tue Mar 17 12:05:10 2015
> >>> New Revision: 1667280
> >>>
> >>> URL: http://svn.apache.org/r1667280
> >>> Log:
> >>> Always install a .mine file for conflicted binary files, not just in
> >>> case the binary file was detranslated.
> >>>
> >>> This makes the 'mine-full' option work again from the conflict prompt.
> >>> Before this change, an assertion in libsvn_wc failed when the 'mine-full'
> >>> option was used since no path for 'mine' was recorded in conflict storage.
> >> I think it is better to make the interactive conflict resolver work the way
we
> always installed binary conflicts since 1.0, than to change the way we install
> conflict markers for a bugfix of the conflict resolver.
> >>
> >> In case of conflicts of a binary file there is no pre-merged file with conflict
> markers and therefore we just leave the 'mine' file just where it is... At the
> original location.
> >> (For text conflicts we move it to a different location, and then install the
pre-
> merged file with conflict markers there)
> >>
> >>
> >> This patch introduces a second copy of the same file, while clients always
> had to handle this case for 1.0-1.8 anyway.
> >>
> >>
> >> If the interactive conflict resolver needs a patch, we should probably also
> backport this patch.
> >>
> >> 	Bert
> >>
> > The problem is that choosing 'mine-full' crashes in libsvn_wc.
> > Are you suggesting we shouldn't offer the 'mine-full' option for binary files?
> 
> What does providing that option have to do with creating a duplicate
> file in the WC?

(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


Mime
View raw message