6

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!

  • Whatever you do going forward, don't just delete the old files. To reiterate the remark in the answer below, make a gzipped tarball (or zip file, or whatever) of the whole mess, from its top-level directory down, and archive it somewhere (preferably several somewheres). Disk space is cheap nowadays, many orders of magnitude cheaper than the man-hours rewriting what you've lost in case the migration screws up in some unanticipated way. – John Forkosh Jan 23 '16 at 8:35
6

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.

3

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.

  • 2
    I would learn toward this. Add it all during the initial commit, then the second commit is removing all those old files. – RubberDuck Jan 23 '16 at 11:08
  • Actually, what I am proposing (and what the script does), is to import each individual version into the repository as an individual commit with the author date of the commit set to the date of the snapshot and keep the history. – Jörg W Mittag Jan 23 '16 at 12:00
2

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.