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