What do you do in your source control repository when you start a rewrite of a program?

Question

I wrote an application a while back and have been maintaining it for a while now, but it's gotten to the point where there's several major new features to be added, a ton of changes that need made, and I know quite a few things I could do better, so I'm starting a rewrite of the entire program (using bits and pieces from original).

My question is, what do you do with SVN at this point? Should I put the new version somewhere else, or should I delete the files I no longer need, add the new files, and just treat it like normal development in SVN?

How have you handled this in the past?

Answer 1

I would create a branch. If you need to go back and make some changes in the trunk you can merge the changes from the trunk to the branch keeping the branch in synch with the current version

Answer 2

1) If the old version has almost nothing in common (code wise) with the new one except the name then I'd create a new project in subversion. e.g. if old product is called program then you could call it program2 or something like that.

Or I might do this if the project structure is also very different.

2) If it is similar then branch the trunk to somewhere and name it version 1 or whatever (you might need to change that branch later for some reason). Delete the files not being used and create the new ones as required.

Your choice. There are no right or wrong answers here.

Answer 3

Assuming your application is live, I'd refactor it slowly and commit all changes.

If some of your changes are large (you'd probably "feel" the limit, "will this change potentially damage other parts of the system or is it a small fix?"), you should start a branch which, when completed, merge it with the working system. There's no harm in branching a lot.

Since you got a working copy at the moment, tag it and leave it be. It's always good to have a backup plan. I wouldn't throw it out because.. well, refactoring old code almost always beats rewriting because of all the business rules which are embedded (and probably forgotten) somewhere deep in there...

Answer 4

If you can refactor incrementally, do it; it's both the fastest and allows you to have working version all the way. Otherwise... will the old version continue to be developed/supported? If so, branch it. If not, tag it and continue commiting to the head. Or, if your new project is really a completely new project (for example same app but completely different technology and most of the old files removed), commit a new project to repository.