> On Fri, Mar 09, 2012 at 10:45:13AM -0700, Geoff Hoffman wrote: > > A couple of things I find interesting... the bug tracker you linked to > > is 3 years old and still on tigris.org. Assuming that is still the > > valid place for tracking subversion features & bugs? > > The issue tracker has not been migrated to apache.org yet. > See http://subversion.apache.org/reporting-issues.html#queries > > The bug is 3 years old because someone had the same feature idea 3 years > ago, filed an issue, and nothing has happened since. > > > Hypothetically speaking, how would svn revert --recursive *--force* > > PATH be different/better than svn cleanup *--remove-unversioned-files* > > PATH (a bit verbose IMO)? I guess it does make more sense for the > > proposed feature to be a switch on svn cleanup. > > svn revert deletes some unversioned files in certain circumstances. > This was recently discussed here: > http://thread.gmane.org/gmane.comp.version-control.subversion.devel/134154 > > In my opinion removing unversioned data is not the job of 'svn revert'. > It is supposed to roll back the working copy into the state that it was in > after the > last checkout or update. In other words, it destroys changes made to > *versioned* files and directories. > > Anyway, which subcommand this feature belongs in is a question that should be > answered by a concrete design proposal. It doesn't really matter all that > much. > > > This is such great advice. If as many people would give to open source > > as take from it, imagine how much richer everything would be? > > Yes, and the world would be full of flying pigs, too! > > > I went over to http://subversion.apache.org/download/ and was > > surprised there doesn't seem to be an svn checkout option, even read > > only? > > See http://subversion.apache.org/source-code.html (linked from the very > bottom of the download page -- perhaps not as easy to find as it should be).
I expect this issue hasn't been actioned because it is so easy to mitigate by the developer... 1. Ensure your build artifacts are kept separate or group in a folder. 2. Create a clean batch or shell file that removes all the build artifacts. Personally, I have a clean.bat file in our project root that deletes all the bin and obj folders (Visual Studio inherently keeps them in their own folders) recursively. It took about 5 minutes to create and commit. That said, I don't object to a --include-unversioned --include-ignored switches to svn CLI. BOb
