Purging the testHistory fails when using Subversion / Git

[aphofstede]

See also: http://sourceforge.net/p/fitnesse/bugs/24/

When FitNesse is under Version Control with Subversion, the purging of the testHistroy fails.
This is because Subversion adds a .svn directory in every directory of FitNesse.
The Purge now scans the .svn directory too and wants the delete the files in the .svn directory.
This causes a ParseException.
The .svn directory should not be included when purging the testHistory.

Same applies for git.

[mwarhaftig]

Looks like as of Subversion 1.7 (released 10/2011) only the working directory gets a .svn subdirectory (http://stackoverflow.com/questions/9070190/svn-no-longer-writes-svn-in-all-sub-folders). Also, all Git releases only add a .git file to the top level directory.

This limits the chances of testHistory having a .svn or git subdirectory but obviously it can happen. Let me see if I can find a good way to handle these files.

[linquize]

Do you mean to run git clean -fxd?

[mwarhaftig]

Referenced pull request updates testHistory purge logic to remove hidden subdirectories if all other files within directory will be purged.

[amolenaar]

I was just wondering. FitNesse does not create any directories in the directories that contain the history xml files. Shouldn't we just leave directories alone? Not removing the test history directory. I mean: if people (or other tools for that matter) put extra stuff in those folders it's their problem right? We can just leave it be.

[mwarhaftig]

My reason for deleting hidden directories was to prevent older SVN versions from permanently having empty testResults subdirectories for all run tests.

But I don't have strong feelings about the need to delete...

[mwarhaftig]

@amolenaar currently whenever the purge encounters a file that is not test history it logs a severe error since it doesn't know if it should delete that file. Should we just not log non-test history files as an error?

[amolenaar]

I think we should not use severe errors then. Just leave them be, maybe log a warning (or on info level), since we do not expect such files to be there?