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.
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?