subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Mielke <m...@mark.mielke.cc>
Subject Re: Subversion in 2010
Date Tue, 05 Jan 2010 06:02:07 GMT
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@mielke.cc>


Mime
View raw message