[Svnmerge] svnmerge between multiple repositories, same repo path

[Karsten Sperling]

You could always make it configurable during svnmerge init and then keep
using whatever format is in the property.

Jack Repenning wrote:
> On Apr 9, 2007, at 4:13 PM, dustin at zmanda.com wrote:
> 
>> On Mon, Apr 09, 2007 at 03:10:26PM -0500, dustin at zmanda.com wrote:
>>> I'd like to use svnmerge to manage merges between two different
>>> repositories containing the same projects.  Basically, I'd like to merge
>>> bidirectionally between:
>>>
>>>   http://server1/svn/project/trunk
>>>   http://server2/svn/project/trunk
>>>
>>> My expectation was that svnmerge wouldn't be able to merge between
>>> different repositories, but it seems to support this. To my surprise,
>>> what it *can't* do is merge between two locations with the same repo
>>> path (in this case, /project/trunk).  The svnmerge properties make the
>>> reason clear: only the repo path is used to identify a branch.
>>>
>>> Is there a way around this?
>>
>> I think I answered my own question:
>>
>> remove_username_re = re.compile("/[^/]*@")
>> def target_to_repos_relative_path(target):
>>     url = target_to_url(target)
>>     # remove '@xxxx', since that's usually user-specific for e.g., an
>> svn+ssh repo
>>     url = remove_username_re.sub("/", url)
>>     return url
>>
>> This does what I need -- changes the identifiers used in merges to be
>> full
>> urls, minus the username if one was provided.
> 
> Huh.
> 
> I have sort of the opposite case: I have some repository hosts that some
> clients refer to by one name, and some by another (due to gateway
> issues).  One set of names can be used by everybody, albeit with some
> performance loss for some; the other set is only usable by some of the
> clients.  Under certain scenarios, therefore, your change would leave
> the inaccessible names in the props, right?  And hence, folks who
> couldn't use that name would be unable to benefit from svnmerge's
> history-keeping.  Right?  I haven't verified this, nor have I really
> thought through all the scenarios to see if there's some viable
> work-around.
> 
> I'm not sure whether my case or yours is the more obscure, but if I may
> be totally selfish, I'd hate for *my* favorite corner case to be broken
> by the fix to yours! ;-)
> 
> 
> -==-
> Jack Repenning
> jrepenning at collab.net
> 
> There are two ways of constructing a software design. One way is to make
> it so simple that there are obviously no deficiencies. And the other way
> is to make it so complicated that there are no obvious deficiencies. The
> first method is far more difficult.
>  - C.A.R. Hoare
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Svnmerge mailing list
> Svnmerge at orcaware.com
> http://www.orcaware.com/mailman/listinfo/svnmerge


-- 
Karsten Sperling | Software Developer | RHE & Associates Limited
Mobile +64 21 0 521 512 | Office +64 9 377 8341 | AIM KarstenRHE
Ground Floor, Equitable House, 57 Symonds St, PO Box 67 067, AKL