[Svnmerge] Some un-clarity in the wiki tutorial [attn: Giovanni Bajo]

[Paul Walmsley]

>> What this old and possibly outdated tutorial is trying to say is that
>> it's better to run "svnmerge.py init" immediately after branch creation,
>> before doing any work on it.
>>     
>
> Yeah, I understand it's saying that... but why?
>   
In my experience, it seems that "svnmerge.py init" won't detect the 
branch point if you run it some time after the branch was created, so I 
find that I need to explicitly specify the branch revision with 
"svnmerge.py init -R 1-1000 ...".   Maybe this is specific to the use 
case where you're working on the trunk and are wanting to merge in 
changes from a branch? (the wiki tutorial is for the opposite case of 
merging from trunk to branch)

In the case that you've just created the branch, the merge point will be 
quite unambiguous.
>>
>> It basically tries to find out two things:
>>
>> 1) the URL of the branch's head (eg: trunk).
>> 2) the revision number at which the branch has been generated off its
>> head. 
>>     
>
> All of which is entirely independent of local modifications, right?
>   
Yes, although, as I mention above, I don't find it very reliable at 
detecting the revision of the branch point.

>>>   it seems to me that it shouldn't care about the local state of
>>>   the working copy.  Is it really correct that you can't have local
>>>   modifications?
>>>       
>> No, snvmerge.py doesn't specifically care about the working copy status;
>> the fact that it checks for local modifications and abort if there are
>> any, is just to save you from operational mistakes (where you have some
>> local modification that gets accidentally committed within a merge). 
>>     
>
> I'm still not seeing what this saves you from in the case of
> "svnmerge.py init."  Maybe the check should be disabled in that case.
>   
I think the main reasons for having a pristine working copy are:

    * There is much less scope for things going wrong on a pristine WC,
      compared to one which might have files in a variety of states --
      some local changes, some files added but not committed, different
      directories at different revisions, etc
    * A common usage pattern is to checkout a pristine WC, invoke an
      svnmerge command and then commit (since the svnmerge command
      generates a file svnmerge-commit-message.txt containing a useful
      summary of the merge):

      svnmerge merge ... && svn commit -F svnmerge-commit-message.txt 

      If you have other local changes then the commit will include them
      (unless you commit with the non-recursive -N flag), which I think
      is rarely what you want.  Hence the emphasis on clean checkouts.

I would reinforce the advice on using clean checkouts for all merge work 
-- it does make things a lot more manageable.  The principle of least 
surprise, I would say.

Paul