Lars Kruse <lists@sumpfralle.de> writes:
> ah - good question - now we can clear up the confusion:
> for now I was always talking about the top directory of my local working copy.
> Thus this is not a name of an item within the repository, but just the name of
> a directory within my local filesystem.
>
> Then I did some more tests and now the problem seems to be clear:
>
> (1) svn mkdir _svn
> output: svn: Not enough arguments provided; try 'svn help' for more info
>
> (2) svn up SOMEDIR/_svn
> result: svn always tries to update the _current_ directory - no matter, what
> SOMEDIR contains
>
> (3) svn co https://systemausfall.org/svn/lars _svn
> result: a local directory named "lars" is created, instead of "_svn"
>
> It looks like svn simply ignores any command line argument ending in ".svn" or
> "_svn", since all of the above examples show the behaviour, that would happen
> _without_ the specific argument.
>
> So my previous assumption, that the svn CLI removes the last part of a
> directory if it is ".svn" or "_svn" was wrong.
> Instead, it completely ignores all the arguments that happen to end in one of
> these magic strings.
>
> I hope, this helps to clarify the problem,
Yes, very much!
This sounds like buggy behavior, independently of whether "_svn" is
treated like ".svn" -- we shouldn't be treating either of them in this
way! That is, if we're going to protect ".svn" (and maybe "_svn")
from being targets, this is not the right way to do it anyway.
Do these behaviors all reproduce with the latest trunk Subversion? If
you have time to test, that would be very helpful. If not, I'll try
to do it soon and file a bug.
Thank you,
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Nov 19 07:35:15 2007