[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn merge remote server versions to local workspace

From: Jerry Pendergraft <jerry.pendergraft_at_parvenu.com>
Date: 2007-12-31 16:53:53 CET

On 27 Dec, 2007, at 13:37 , Ryan Schmidt wrote:

>
> On Dec 27, 2007, at 13:30, Jerry Pendergraft wrote:
>
>> Tried something seemingly simple that did not work as expected.
>> $ svn merge <remote>@N <remote>@M .
>>
>> According to the svnbook the result should be getting the
>> difference between N and M and applying it to .
>> But it fails with a message about mixing access methods .... huh?
>>
>> In fact $ svn diff <remote>@N <remote>@M does indeed produce a
>> patch with difference between N and M.
>>
>> So why should the type of the local workspace matter?
>
> What OS is on the server and client? What version of svn is on the
> server and client? What is the repository access method in your
> merge statements? What is the repository access method in your
> working copy? Is your working copy from the same repository as the
> one from which you're trying to merge, or is it a different
> repository?
>
No idea what OS or svn version is on the server at University of Utah.
Local version is 1.45 on RHEL Linux.
The access method in the merge statements was https:...@N https:....@M
The local repository is file:///.....

So it is true that server and local are different access methods, but
I can't understand why that would matter since the operation is using
the https method on the server to generate a patch and apply it to the
current workspace. So again why should the local workspace method
matter. Aren't workspace (.) operations always just file access ?

>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>

--
Jerry Pendergraft
jerry.pendergraft@parvenu.com
Received on Mon Dec 31 16:54:03 2007

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.