What fun. Looks like a good friend of mine, James Johnson (also the president of the IE .Net User’s Group) got attacked by a potential SQL injection. Fortunately he’s pretty up on his secure coding so it wasn’t a problem. Props to James!
Anyway, he threw it my way because he thought I’d be interested. Was a pretty nasty one. Take a look at his write up and you can also see my comments there.
This was a question I got from a colleague today.
In my experience (which certainly isn’t exhaustive) a clean up is required when I’ve done something that svn didn’t expect. Typically this is where I’ve manipulated files on my own without using the TortoiseSVN tools. Eventually they get in such a state that svn simply doesn’t know how to resolve things. One example comes to mind where I have deleted my .svn folder in a directory. Now, according to svn, that directory is suddenly missing and an unversioned directory of the exact same name exists, and therefore cannot be replaced.
In many cases the Clean Up tool can fix simple mistakes, but in the example above svn simply needs help. If I can’t fix what’s going on then I’ll typically just delete the entire project folder and check out a brand new copy. This is usually far faster than actually trying to fix what went wrong. If I have made changes that I don’t want to loose then I check out the project into a brand new directory, add the changes to that version (either through VS 2008 or by just manually dragging over files) and do any manipulation such as renames, deleted, etc with Tortoise-svn.
Just yesterday I was working with an SSRS 2005 project. Our set of reports had grown over time so we decided to organize them into folders. VS 2005 cannot do this. Our strategy was to create one solution for the set of reports, containing a separate project for each subgroup. This really helped organize everything, but there was no simple way to do this using VS 2005 and svn. Either we create the new projects and moverename all the reports between projects using VS 2005, and svn was totally lost, or we did everything in svn, which confused VS 2005 and ultimately broke a lot of links.
I decided on the first option, to simply do it all in VS 2005 then commit the changes in svn. svn reported a lot of missing files and a lot of unversioned files after the change but I just marked the missing ones as deleted and committed the unversioned ones. While I technically lost the history in svn of the development of the files I have rarely needed to view changes past a few revisions and I think any intelligent person can see what we did.
Technorati Tags: Clean Up