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

Re: Subversion in 2010

From: Mark Mielke <mark_at_mark.mielke.cc>
Date: Tue, 05 Jan 2010 01:02:07 -0500

On 01/04/2010 02:32 PM, Stefan Sperling wrote:
> On Mon, Jan 04, 2010 at 01:45:07PM -0500, Mark Mielke wrote:
>
>>
>> If it doesn't resolve them (any? all?) yet, then this would explain
>> one of the results I saw and couldn't explain. It knew the files had
>> moved, it said it completed the merge - but the merge was missing. I
>> became too busy to chase it down! :-(
>>
> Out of curiosity, where did you get the idea from that Subversion
> could resolve tree conflicts for you?
> Is there documentation which is not clear enough and needs to be fixed?
>

The release notes and the documentation. Reading it closer - I see that
it clearly states "detection" and not "resolution", however, I think a
casual reader or an optimistic reader, such as myself, would easily come
to the conclusion that "detection" implied resolution. That is, why
detect if the knowledge will not be used to make the right decision?

Reading it again, I am still failing to see why detection would not
imply resolution. If the code can figure out what happened - why can it
not act on this knowledge? If we know that A moved to B at the same time
as it changed from revision X to revision Y, why not do the three way
diff between A:X, B:Y, and the source?

I understand that the architecture limits what can be stored - but if
you review something like GIT, they do not store renames either. They guess.

Personally, I prefer a good guess and an often good decision over a
guess that is reported even though it still does the wrong thing
(current behaviour?), no guess at all (previous behaviour?), or complete
failure (also current behaviour in some situations?).

I am a believe in refactor early, refactor often, especially before
release of a product. Refactor with languages such as Java or even
scripting languages such as Perl, often require renames. When following
this sort of design practice - renames with minor changes become very
common. In these cases, being able to guess the rename or move, and then
propagate the change across it, it EXTREMELY valuable. Conversely,
failures for it to handle this common situation ranges from annoying to
complete loss of productivity and failure to release the product on time.

What is required to take detection to the next step?

Cheers,
mark

-- 
Mark Mielke<mark_at_mielke.cc>
Received on 2010-01-05 07:02:47 CET

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