8

I've got an SVN repository of a PHP site and the last programmer didn't use source control properly. As a result, only code since I started working here is in the Repo.

I have a bunch of old copies of the full code base saved in files as "backups" but they're not in source control. I don't know why most of the copies were saved nor do I have any reasonable way to tag them to a version number. I do have the dates the backups were made, all backups have proper file system timestamps.

Due to upgrades to the frameworks and database drivers involved, the old code is quite defunct; it no longer works on the current server configuration. However, the previous programmers had some unique logic, so I hate to be completely without old copies to refer to what on earth they were doing.

Should I keep this stuff in version control? How? Wall off the old code in separate Tags/branches?

2
  • Do you have a full copy of the current code base in source control now? Commented Apr 9, 2012 at 15:30
  • @JoshuaDrake yeah, the current repo is a complete working copy of everything I need. There's nothing I'm "missing" except for historical stuff, but I've made substantial changes to many parts of the program.
    – Zelda
    Commented Apr 9, 2012 at 15:33

3 Answers 3

10

If you have reasonable timestamps on each of these working versions then perhaps you can check them in one at a time until you get to the most recent version of the codebase, your latest changes.

The problem with the Tag approach like everybody else suggests is that you will lose changeset history on each file and this will make comparisons between older versions of the code more difficult.

7
  • I was wondering if I could get them into revision history. The Modified dates do look accurate on the old copies.
    – Zelda
    Commented Apr 9, 2012 at 15:59
  • 3
    @BenBrocka Obviously you can yes, you just start by checking the oldest copy of the codebase into a fresh branch. Delete everything in your working copy except for the subversion directories, copy the next oldest copy into your working folder, Check for modifications, you will see all the new files, updates, and deletes. Check in. Lather. Rinse. Repeat until you have elegant shiny hair.
    – maple_shaft
    Commented Apr 9, 2012 at 16:03
  • 2
    NOTE: Doing this you will lose the historical timestamps on the previous versions, but those dates are probably not very useful anyways besides historical curiousity. The sequential changeset history for each file is much more valuable.
    – maple_shaft
    Commented Apr 9, 2012 at 16:10
  • 1
    There's no way I can keep the historical timestamps anyway, right? They'll just show up as the oldest revisions?
    – Zelda
    Commented Apr 9, 2012 at 16:50
  • 2
    Sure you can keep the timestamps. Given a stand-alone system (e.g., a laptop, a PC desktop), just set your clock to the timestamp of the backup before checking in to SVN. Commented Apr 10, 2012 at 18:17
8

I would use a separate dir, something like "legacy" to have all the necessary Stuff in one Place.

1
  • +1 Document how the different versions relate, save, go forward with the working copy. Commented Apr 10, 2012 at 1:32
2

I personally would. You do need to make sure that you keep them all separate, probably like you said, wall it off with tags. You might be able to use the date the file was last edited to figure out a general order of things.

Putting it in SVN would about be good to kind of show the history. It sounds like you'll need it, if they have some odd snippets seeing the file's history would be useful. Not to mention you have the entire (known) history of the project in one place. Can't really think of a reason not to, although I could be missing something important.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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