On Apr 9, 2007, at 4:13 PM, [EMAIL PROTECTED] wrote:

On Mon, Apr 09, 2007 at 03:10:26PM -0500, [EMAIL PROTECTED] 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
[EMAIL PROTECTED]

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
[email protected]
http://www.orcaware.com/mailman/listinfo/svnmerge

Reply via email to