You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by "A.T.Hofkamp" <a....@tue.nl> on 2005/09/05 13:43:48 UTC

how to predict copy behavior?!

Hai all,

Under the assumption that svn is just a versioned file system, can someone 
explain why a cp at the file system and a copy in svn do different things below?

File system (linux):
====================
%  mkdir -p vendors/asc-support/current
%  mkdir -p trunk/asc-support
%  touch vendors/asc-support/current/foo-file
%  mkdir vendors/asc-support/current/foo-dir
%  touch vendors/asc-support/current/foo-dir/more-foo-file

here, I have vendors/asc-support/current/{foo-file,foo-dir/more-foo-file} and 
trunk/asc-support

%  cp -r vendors/asc-support/current/. trunk/asc-support

copy recursively, the contents of current/. to trunk/asc-support

%  ls -l trunk/asc-support
total 4
drwxrwx--x  2 hat hat 4096 Sep  5 15:12 foo-dir/
-rw-rw----  1 hat hat    0 Sep  5 15:12 foo-file

qed :-)


Svn (file:///local/asfsdf/svn_repo):
====================================
/vendors/asc-support/current/{Makefile, etc etc} exists
/trunk/asc-support exists (and is empty)

% svn copy \
   file:///local/asfsdf/svn_repo/vendors/asc-support/current/. \
   file:///local/asfsdf/svn_repo/trunk/asc-support

% svn ls file:///local/asfsdf/svn_repo/trunk/asc-support
current/

qeh?
[obviously, svn cp != cp ]

This kind of things happens often with me, for some reason copying and moving 
files/dirs at the file system is easy (I almost never make mistakes there), 
while with svn I often end up with a result I don't intended/wanted.

While these things can be fixed by a few more moves, it would be nice if I 
could better predict what svn would do.

How do you remember/predict what svn will do?

Albert

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

Re: how to predict copy behavior?!

Posted by Vincent Starre <vs...@comcast.net>.
Ben Collins-Sussman wrote:

> Vincent Starre wrote:
>
>> My main problem with svn cp and import commands are the lack of a way to
>> see what the tree will look like before and after an operation, without
>> actually performing the operation.
>
>
> So what do you recommend?  How would you improve things?
>
>
I feel that absolutely everything should take --dry-run, even things 
where it doesnt seem to make sense :)

-------------------------------------------------------
C:\>svn import c svn+ssh://deknez/r3wt/svn/tst/branches/c -m ""

Log message unchanged or not specified
a)bort, c)ontinue, e)dit
c
Adding         c\a
Adding         c\b
Adding         c\c
Adding         c\d
Adding         c\d\e
Adding         c\d\f

Committed revision 14.
-------------------------------------------------------

This tells you which local files were committed, but makes no mention of 
the remote structure-
for example "tst" did not previously exist.

meanwhile, this command evidences the need for a "dry run".
C:\>svn import c svn+ssh://deknez/r3wt/svn/tst/branches/ -m ""

if "branches" already exists, this creates 'c' under 'branches. 
otherwise, it creates only 'branches'.
Similar to a normal system "cp", only creating any extra directories 
along the way.

Yes, everyone learns to deal with it as they use it, but offering a 
better way
to avoid worthless oops commits, for those first starting, is always a 
good thing. And, of course,
some of us have alias rm='rm -i' in our .profiles even after years of 
experience- it's nice to get an
"are you sure?" sometimes.

On a related note, it seems that svn cp does /not/ create leading up 
directories. it is not entirely
unoften that I am put off by needing an extra mkdir commit to create a 
"tags" directory. (of course
everyone just tells me "plan ahead")

in short: warnings = GOOD, errors = Annoying! ;)

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

Re: how to predict copy behavior?!

Posted by Ben Collins-Sussman <su...@collab.net>.
Vincent Starre wrote:

> My main problem with svn cp and import commands are the lack of a way to
> see what the tree will look like before and after an operation, without
> actually performing the operation.

So what do you recommend?  How would you improve things?



-- 
www.collab.net  <>  CollabNet  |  Distributed Development On Demand

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

Re: how to predict copy behavior?!

Posted by Vincent Starre <vs...@comcast.net>.
Sorry about that, sussman. My "Reply" button has been thoroughly 
murdered for its crimes against the state.

My main problem with svn cp and import commands are the lack of a way to
see what the tree will look like before and after an operation, without
actually performing the operation. The fact that the summary of
operations which appears while comitting does not include the full path
is rather disturbing for server-side operations.
Once again I'll just assume that nobody agrees with me here.

Ben Collins-Sussman wrote:

>
> On Sep 5, 2005, at 11:22 AM, A.T.Hofkamp wrote:
>
>> Ben Collins-Sussman wrote:
>>
>>> On Sep 5, 2005, at 8:43 AM, A.T.Hofkamp wrote:
>>>
>>>>
>>>> This kind of things happens often with me, for some reason  
>>>> copying  and moving files/dirs at the file system is easy (I  
>>>> almost never  make mistakes there), while with svn I often end up  
>>>> with a result I  don't intended/wanted.
>>>>
>>> Both 'svn cp' and 'cp' follow the same basic rule when you run  
>>> 'copy  A B':
>>>    if B exists:
>>>      create B/basename(A)
>>>    else:
>>>      create B, where B == basename(A)
>>>
>>
>> I don't understand what you mean by "where B == basename(A)", does  
>> that imply that you throw away the name B in the latter case?
>>
>
> Sure, if I run 'svn cp foo/bar/ baz/bop/', and 'baz' is an empty  
> directory, then the 'bop' subdir will be created, and it will be an  
> identical copy of 'bar'.
>
>
>
>> cp at least doesn't do this, 'cp -r A B' for non-existing B does
>>
>> 1. create B
>> 2. 'cp -r A/* B' (with * also including the hidden files/dirs).
>>    (copy all files in A to B/.)
>
>
>
> I think we're describing the same thing here.
>
>
>>
>>
>>
>>> There are two differences, however, that I'm aware of:
>>>    1. subversion always canonicalizes "/foo/bar/baz/."  into "/ foo/ 
>>> bar/baz",
>>>       for every command, I think.
>>>
>>
>> This prevents me from copying contents of a directory in one command.
>> While this can be worked around, being able to refer to "all files  
>> in directory X" seems a useful concept for svn.
>>
>> Are there other ways to express this concept?
>>
>
> Not at the moment.
>
>
>>
>>>    2. 'svn cp' only takes two arguments, instead of N arguments.
>>>
>>
>> so I found out :-)
>> Not a major problem imho.
>>
>
> Sure it's a major problem.  If it worked, you could run 'svn cp A/*  
> B' and get what you want.  :-)
>
>



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

Re: how to predict copy behavior?!

Posted by "A.T.Hofkamp" <a....@tue.nl>.
Ben Collins-Sussman wrote:
> 
> On Sep 5, 2005, at 11:22 AM, A.T.Hofkamp wrote:
> 
>> Ben Collins-Sussman wrote:
>>
>>> On Sep 5, 2005, at 8:43 AM, A.T.Hofkamp wrote:
>>>
>>>>
>>>> This kind of things happens often with me, for some reason  copying  
>>>> and moving files/dirs at the file system is easy (I  almost never  
>>>> make mistakes there), while with svn I often end up  with a result 
>>>> I  don't intended/wanted.
>>>>
>>> Both 'svn cp' and 'cp' follow the same basic rule when you run  
>>> 'copy  A B':
>>>    if B exists:
>>>      create B/basename(A)
>>>    else:
>>>      create B, where B == basename(A)
>>>
>>
>> I don't understand what you mean by "where B == basename(A)", does  
>> that imply that you throw away the name B in the latter case?
>>
> 
> Sure, if I run 'svn cp foo/bar/ baz/bop/', and 'baz' is an empty  
> directory, then the 'bop' subdir will be created, and it will be an  
> identical copy of 'bar'.

So the thing to remember is that svn cp _always_ creates a directory when 
copying directories, while cp sometimes doesnot (since '.' means 'all files' 
rather than 'directory').

Tnx!
Albert

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

Re: how to predict copy behavior?!

Posted by Ben Collins-Sussman <su...@collab.net>.
On Sep 5, 2005, at 11:22 AM, A.T.Hofkamp wrote:

> Ben Collins-Sussman wrote:
>
>> On Sep 5, 2005, at 8:43 AM, A.T.Hofkamp wrote:
>>
>>>
>>> This kind of things happens often with me, for some reason  
>>> copying  and moving files/dirs at the file system is easy (I  
>>> almost never  make mistakes there), while with svn I often end up  
>>> with a result I  don't intended/wanted.
>>>
>> Both 'svn cp' and 'cp' follow the same basic rule when you run  
>> 'copy  A B':
>>    if B exists:
>>      create B/basename(A)
>>    else:
>>      create B, where B == basename(A)
>>
>
> I don't understand what you mean by "where B == basename(A)", does  
> that imply that you throw away the name B in the latter case?
>

Sure, if I run 'svn cp foo/bar/ baz/bop/', and 'baz' is an empty  
directory, then the 'bop' subdir will be created, and it will be an  
identical copy of 'bar'.



> cp at least doesn't do this, 'cp -r A B' for non-existing B does
>
> 1. create B
> 2. 'cp -r A/* B' (with * also including the hidden files/dirs).
>    (copy all files in A to B/.)


I think we're describing the same thing here.


>
>
>
>> There are two differences, however, that I'm aware of:
>>    1. subversion always canonicalizes "/foo/bar/baz/."  into "/ 
>> foo/ bar/baz",
>>       for every command, I think.
>>
>
> This prevents me from copying contents of a directory in one command.
> While this can be worked around, being able to refer to "all files  
> in directory X" seems a useful concept for svn.
>
> Are there other ways to express this concept?
>

Not at the moment.


>
>>    2. 'svn cp' only takes two arguments, instead of N arguments.
>>
>
> so I found out :-)
> Not a major problem imho.
>

Sure it's a major problem.  If it worked, you could run 'svn cp A/*  
B' and get what you want.  :-)


-- 
www.collab.net  <>  CollabNet  |  Distributed Development On Demand




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

Re: how to predict copy behavior?!

Posted by "A.T.Hofkamp" <a....@tue.nl>.
Ben Collins-Sussman wrote:
> 
> On Sep 5, 2005, at 8:43 AM, A.T.Hofkamp wrote:
> 
>>
>> This kind of things happens often with me, for some reason copying  
>> and moving files/dirs at the file system is easy (I almost never  make 
>> mistakes there), while with svn I often end up with a result I  don't 
>> intended/wanted.
> 
> 
> Both 'svn cp' and 'cp' follow the same basic rule when you run 'copy  A B':
> 
>    if B exists:
>      create B/basename(A)
>    else:
>      create B, where B == basename(A)

I don't understand what you mean by "where B == basename(A)", does that imply 
that you throw away the name B in the latter case?

cp at least doesn't do this, 'cp -r A B' for non-existing B does

1. create B
2. 'cp -r A/* B' (with * also including the hidden files/dirs).
    (copy all files in A to B/.)


> There are two differences, however, that I'm aware of:
> 
>    1. subversion always canonicalizes "/foo/bar/baz/."  into "/foo/ 
> bar/baz",
>       for every command, I think.

This prevents me from copying contents of a directory in one command.
While this can be worked around, being able to refer to "all files in 
directory X" seems a useful concept for svn.

Are there other ways to express this concept?

>    2. 'svn cp' only takes two arguments, instead of N arguments.

so I found out :-)
Not a major problem imho.


Albert

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

Re: how to predict copy behavior?!

Posted by Ben Collins-Sussman <su...@collab.net>.
On Sep 5, 2005, at 8:43 AM, A.T.Hofkamp wrote:
>
> This kind of things happens often with me, for some reason copying  
> and moving files/dirs at the file system is easy (I almost never  
> make mistakes there), while with svn I often end up with a result I  
> don't intended/wanted.

Both 'svn cp' and 'cp' follow the same basic rule when you run 'copy  
A B':

    if B exists:
      create B/basename(A)
    else:
      create B, where B == basename(A)

There are two differences, however, that I'm aware of:

    1. subversion always canonicalizes "/foo/bar/baz/."  into "/foo/ 
bar/baz",
       for every command, I think.

    2. 'svn cp' only takes two arguments, instead of N arguments.

        In other words, if you run 'svn cp *.txt blah/', the shell  
expands
        this to 'svn cp 1.txt 2.txt 3.txt blah/', which causes an error.
        This is a very old, filed bug.



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