On 4/22/2006 9:45 PM, Keng Lam wrote:
> Thanks Duncan and Rahul for clarifying. I like Rahul's idea of
> using command syntax like rcopy. Not sure the backward compatability
> requirements leave any room open for suggestions like these.
As I explained to you, that option would not work. There are 4 kinds of
copy, since source and dest can each be in the repository or in the
working copy. There would need to be 3 new kinds of commands, not just
one new kind, and that just doesn't make any sense. The "remote" marker
needs to be attached to the source or dest argument, not to the command.
In my opinion, the use of URL syntax is as good a marker as any other,
but if you want a different sort of marker, follow my advice and set it
up yourself.
Duncan Murdoch
>
> Thanks much.
>
>> ----- Original Message -----
>> From: "Rahul Bhargava" <rahul@wandisco.com>
>> To: "Keng Lam" <keng-lam@lycos.com>, users@subversion.tigris.org
>> Subject: Re: svn URL semantics help
>> Date: Sat, 22 Apr 2006 18:21:37 -0700
>>
>>
>> Duncan Murdoch wrote:
>>> On 4/22/2006 12:25 PM, Keng Lam wrote:
>>>> The usage of URL appears to be confusing to me with SVN clients. Please
>>>> let me know if I missed something here -
>>>>
>>>> I am trying to understand the svn commands that take URL as a parameter
>>>> for instance svn copy command. So if I try:
>>>>
>>>> $ svn copy https://dodo/trunk http://mipo/tags/t1
>>>> subversion/libsvn_client/copy.c:357: (apr_err=200007)
>>>> svn: Source and dest appear not to be in the same repository
>>>> (src: 'https://dodo/trunk'; dst: 'http://mipo/tags/t1')
>>>>
>>>> Basically I can't copy across repository. I can only copy relative to
>>>> my current svn repos. If that is the case what's the point of
>>>> having a URL in the destination of commands like copy/mkdir/move ?
>>> I think it's just a simple way to indicate that you want to do a
>>> repository copy, rather than touching the working copy. It could
>>> be done by inventing some new syntax, e.g.
>>>
>>> svn copy repos:/trunk repos:/tags/t1
>> I agree its confusing the way the current syntax stands. Syntax
>> appears to suggest possibilities
>> (cross repos copies) that do not make sense as described by Duncan.
>>
>> Perhaps in future it may be nice to consider the possibility of
>> using "r" commands like CVS.
>> For example in the CVS parlance, "rtag" is different from "tag".
>> The "r" indicates remote server-side
>> action. Subversion could use "rcopy" to indicate server-side action
>> without inventing any
>> new flags. Best Regards,
>>
>> -- Rahul Bhargava,
>> Subversion,CVS Solutions
>> WANdisco,Inc.
>> Pleasanton, CA
>> http://www.wandisco.com
>>
>>
>>
>>> to save typing, but this is hardly worth the trouble: if you
>>> want it, you can do it yourself using environment variables. For
>>> example,
>>>
>>> REPOS=https://dodo
>>> svn copy $REPOS/trunk $REPOS/tags/t1
>>>
>>> The question of why you can't copy between repositories is
>>> different. I think that's because it would be impossible to
>>> maintain history across such a copy. Since "svn copy" is
>>> supposed to maintain history, it can't possibly work.
>>>> Did I miss something or SVN semantics with dest URL are
>>>> confusing ? If I can copy
>>>> only relative to the current repos, won't it be more intutive to
>>>> have a relative
>>>> path option with appropriate flags to indicate that a
>>>> server-side operation needs
>>>> to be triggered as opposed to using an open-ended URL semantics ?
>>> The flags would need to be applied to each argument, since you've
>>> got both src and dest that could be in the repository. I don't
>>> think there are any other cases in SVN syntax where flags apply
>>> to arguments. They apply to the command as a whole.
>>>
>>> Duncan Murdoch
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>>> For additional commands, e-mail: users-help@subversion.tigris.org
>>>
>>>
>>>
>>
>>
>>
>>
>> This email and any attachments may contain private, confidential
>> and privileged material for the sole use ofthe intended recipient.
>> If you are not the intended recipient, please immediately delete
>> this email and any attachments.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
>
>
>
>
> Cheers,
>
> Keng Lam
> System Administrator
> ---
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun Apr 23 16:19:24 2006