Clever clever. I'm still trying to wrap my head around that idea. I'll look again at the patterns.

The fact that no one has heard of this problem makes me think I've missed a source of ignore patterns somewhere. Time to quadruple check. I also see from another reply that the registry is a source of ignore patterns, so I'm going to look there as well.

On Wed, Feb 3, 2010 at 2:59 AM, Felix Gilcher <> wrote:

On Feb 3, 2010, at 12:02 AM, Ryan Schmidt wrote:

> On Feb 2, 2010, at 16:34, Dave Purrington wrote:
>> The scenario goes like this:
>>      • Homer svn deletes a folder and commits to the repository.
>>      • Marge svn updates, and svn reports the folder Homer deleted ("D   <some folder>")
>>      • Marge runs svn st, some folder is not reported as unversioned.
>> However, the folder is still on disk (unversioned, i.e. no .svn folder) and is now ignored (revealed by "svn st --no-ignore"). What's odd is that I can't even tell how it's being ignored. Marge doesn't have a matching pattern in her global ignores, and svn propget svn:ignore on the parent folder reveals nothing useful. All clients using 1.6.6 on Windows.
>> What's also strange is that there are plenty of cases where files or folders are deleted and post update they show up as unversioned items. Why the difference?
> I've never heard of that happening. Do you have a reproduction recipe that can recreate this problem?

Maybe it was ignored after it had been added to the repository (matched by some sort of wildcard pattern or the like). It would show up during regular commits since it's in the repo and items that are versioned cannot be ignored. After deleting however, it would no longer be versioned and thus matched by the ignore. So it would be interesting by which ignore rule it's matched and whether that rule was added after the folder.

Another possibility would be that someone added the folder even though it was ignored from the beginning.


Felix Gilcher

Bitextender GmbH
Paul-Heyse-Str. 6
D-80336 München