[Svnmerge] Initializing New Branches - Already Initialized?

[Raman Gupta]

Thomas F. O'Connell wrote:
> Well, here's my scenario: I have a trunk and often create feature- 
> specific branches that get developed at a variety of paces, but none  
> of which I want to hold up patches to the trunk or merging of other  
> branches. My expectation is that the trunk and branches are all  
> bidirectional (although I've had a hard time deciphering what the  
> best practices are for initial setup and ongoing maintenance of this  
> scenario).
> 
>  From reading the built-in help and the wiki documentation, I had  
> thought that the appropriate way to create a new branch was to create  
> a copy of trunk as a branch and then to initialize both.
> 
> E.g.,
> 
> cd cd working-copy-top-dir
> svn copy trunk branches/new-branch-n
> cd branches/new-branch-n
> svnmerge.py init
> cd ../trunk
> svnmerge.py init -r 1:[revision corresponding to n] [URL to new- 
> branch-n]

Yes, this is correct, except that when you run init on new-branch-n,
you are not providing a source branch, which in this case would be
trunk. So I think what is happening is seeing existing merge
information to various branches on new-branch-n (since this info got
copied over from trunk on the initial branch creation) and thus
producing an error. I think if you specify the trunk URL as an
argument to init on new-branch-n it will work fine.

> Often, I'll need to patch something in trunk as branches are  
> midstream. Then I want to merge a branch back to trunk and possibly  
> merge those changes out to other feature branches.
> 
> Initial setup has been one confusing aspect. In the case above, when  
> I got the error, I went ahead and just used --force to  
> "re-"initialize the new branch(es).

See my comment above.

> I'm also a little unclear about when/how to use -b to my benefit when  
> conducting merges.

In your workflow, I would just use -b all the time -- the only
downside to it is that it is slightly slower because it makes one or
two extra remote calls to check the merge information on the source
branch. It should never cause any problems even when it is not applicable.

> I see all these issues as related to what would strike me as a fairly  
> common usage pattern, and I'd be happy to contribute to improving  
> documentation once I get my head around how best to proceed a little  
> better.

Sounds good.

Cheers,
Raman