Project Cleanup and Version Control Best Practices

Question

Question Background:
I have a rather large project that I started before I learned about a beautiful thing called version control. Now, I have a ton of files labeled with the convention "ProjectName_Date."

Question:
I'm thinking of deleting the old files and starting a new repository with the latest version. However, is that a good practice? Would it be better to try to maintain that history by figuring out what changes were made between files and then store everything in a repository? Or is it better to start from scratch and not risk setting up a questionable repository?

What I've done:
I know the question is subjective, but I've read different articles (like the one here) about best practices and can't find anything helpful regarding this type of issue. It seems like everything assumes that you're starting from scratch.

Any advice in the form of experience or an article is appreciated. Thanks!

Answer 1

I'd say, do not bother with the old snapshots.

Commit current state into the repo and start using it as soon as possible.

Just backup the old snapshots and in a couple of month you will not even remember they've existed.

From experience, when we migrated from CVS to GIT, the old CVS source control was left there for reference, but after a few month nobody needed to ever look at it.

Better invest your time into learning your source control system.

Answer 2

What you have there is version control. I think we can all agree that it is a pretty crappy form of version control, but you at least do have different versions, even if you don't have commit messages.

Why throw away that history?

From what I can gather from your description, it's a three-line script and a matter of minutes to import that history into a VCS. Better to have it than to not have it. It probably took you more time to write this question than it will take to write the script and perform the import.

Something like:

#!/bin/sh

for projectversion in /tmp/project/ProjectName_*; do
  versiondate=`basename $projectversion | sed -e 's/ProjectName_//'`
  rm -rf *
  mv $projectversion/* .
  git add .
  GIT_AUTHOR_NAME=multiple GIT_AUTHOR_EMAIL=multiple GIT_AUTHOR_DATE=$versiondate git commit -m "Automatically import version $versiondate."
done

[NOTE: I didn't check this, and it definitely isn't properly quoted, so use at your own risk. It's just a sketch. Oh, and it also turned out to be seven lines, not three :-D ]

If you have some sort of ChangeLog or NEWS file, you could also use that as the commit message.

Answer 3

If you only have to update/patch/support a single version, then just starting the repository with your last version is a perfectly good idea. Keep a backup of the old versions, just in case, but I'd expect it to be unlikely you'll need it.

However, if you have to support multiple versions of your project, I would recommend making a commit per each of the versions you have to support (don't bother with committing intermediate versions, just make sure to keep a backup of them just in case), and tag them accordingly. For obsolete versions that you no longer have to provide support for, just treat them as if they were non-official versions and don't commit them.