Should I import and merge completely new rewritten version of project into existing SVN repository?

Question

I've got a website that is stored in an SVN repository. I was asked to completely rewrite it from the ground up which I've done which is not yet under version control.

Should I merge my new version into the website's existing repository?

As it's a completely new version it has different files and directory structure than the existing site stored in the repository I can imagine this being an issue when attempting a merge.

The only reason I ask about merging is because is it not good practice to keep all the history of the project in the repository?

In relation to the comments

It seems like people think I've missed the point but I can tell you I did not. I have created a entirely new site that could not be any more different in terms of code, directory structure etc. I decided I would work on this project from an empty directory (clean canvas) and then import into repository at end of project.

Answer 1

If you've re-written it already without using version control I think you've kind of missed the point.

One possible way you could have done it would have been to branch the original version, use that branch to incrementally commit your changes and then merge back to the trunk when finished.

Now that you've done it you are probably best maintaining it as a different version.

Answer 2

You could have worked off of the original repo from the start of the rewrite and this wouldn't be an issue.

You could try merging, but it will probably be very difficult. You could also create a new repo for the new version.

Answer 3

I think the answer really depends on how SVN is being used for the current website. If SVN is used as a way to handle website updates and deployments and it is hard to change the way the environment is configured, then you may need to try and merge, or make one commit that deletes the current content and adds your content.

A better approach in my mind would be to import your code into a new repo, or at least a different branch in the existing repo, and then re-target the website to pull from the new location rather than the existing one.

Answer 4

Create a new repository. If the rewritten application doesn't leverage any of the original codebase, there is nothing to be gained by attempting to merge them. Create a new repo, create new build and deployment scripts, and sunset the old one. Chalk it up as a lesson learned, and build new versions off the original next time around.

Answer 5

As others have said, ideally the new work would have been done under source control. Even a single developer can benefit from the ability to revert, branch and exclude externals.

Moving on, I’d move the trunk of the old project into a tag and then move the current state of the new project into the trunk. This will keep your revision history of the original project and get the new project into where it should be.