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