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

Re: add * ignores new files in subdirectories.

From: Felix Gilcher <felix.gilcher_at_bitextender.com>
Date: Sat, 28 Aug 2010 13:15:34 +0200

Hi David,

Please keep the list on cc.

Von meinem iPad gesendet

Am 27.08.2010 um 22:35 schrieb David H <evolvemeans_at_gmail.com>:

> Felx -- thanks for the prompt response.
>
> It is my feeling that "svn add *" should recurse through subdirectories and grab everything
> that it has not put in version control yet. That should be the default behavior, as it is with
> "import".

As I said before, svn never gets to see the "*". subversion gets handed the full expanded list of files and directories. It won't add files or directories that have been added before, that what you're seeing. Please read up on shell expansion to get an understanding what's happening.

>
>
> It is one thing to have an "ignores" file that is used to *display* information.
>
> But when it comes to skipping items in a directory tree, then it should do ALL by
> default, since this is what one would want and expect from version control in the first place.

Import works differently since it does not operate on partially versioned directories. Doing an svn add * in a directory with only unversioned files/subdirectories will have the same result.

>
> A directory that is "half version controlled" is useless.
>
> Thanks again for your work on subversion.

There is a minor misunderstanding here: I don't work on subversion, you're writing on the users mailing list. I'm just a mortal user.

Felix

>
> David
>
>
> On Fri, Aug 27, 2010 at 3:18 PM, Felix Gilcher <felix.gilcher_at_bitextender.com> wrote:
> Hi David,
>
> the cause is your shell expanding the * to the list of all files in the directory before invoking the command. So in a directory containing the files foo, bar and baz.txt, the command "svn add *" actually translates to "svn add foo bar baz.txt" before the command is executed. Svn never even sees the star. You'll see a similar behaviour with ignored files being added when using "svn add *".
>
> The proper command is "svn add --force ." which adds all new files under the current directory while still taking ignores into account.
>
> Felix
>
> Von meinem iPhone gesendet
>
> Am 27.08.2010 um 21:59 schrieb David H <evolvemeans_at_gmail.com>:
>
>> Subversion Dev team:
>>
>> Thanks for all your hard work. I just began using subversion and it is great.
>>
>> Among other things, it is fast.
>>
>> One complaint.
>>
>> I'm using a Linux system, fyi.
>>
>> As a new user it was my expectation that 'svn add *' called from within the root
>> of my version-controlled root directory would result in *all* changes that had been
>> made within the file system to be scheduled for inclusion on the next commit.
>>
>> Instead, it ignored a whole raft of new files that were buried in subdirectories.
>>
>> It took me a while of poking around to find this out.
>>
>> The behavior I expected was that "svn add *" would schedule a snapshot of the
>> entire directory tree. Of course, to actually make this happen, I had to use the "svn add * --force"
>> option. It's also worth noting that the option "svn add * --depth infinity" also did not add the files that were
>> buried in the subdirectores; they were not added to be included on the next commit.
>>
>> Why would you have subversion skip a bunch of files? That makes no sense.
>>
>> The "import" command conversely, adds all the files in all the subdirectories, when a new directory
>> is first brought under version control.
>>
>> It seems to me, the default behavior should be the obvious behavior. Or maybe there
>> is more that I don't yet understand. If so, I would like to hear.
>>
>> Thanks. It is great software.
>>
>> David Heitzman
>>
>> --
>> Life moves on, whether we act as cowards, or heroes.
>
>
>
> --
> Life moves on, whether we act as cowards, or heroes.
Received on 2010-08-28 13:16:31 CEST

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.