0

I've got a (dirty) production installation of Simple Machines Forum (SMF 1.1.13). It was a clean install, once... about five years, twenty updates, and 40 mods ago. Not to mention the custom code that was patched directly into the code base. This started as a for-fun side project, and didn't have any code management practices at the get-go.

Now SMF 2 is (getting closer to) going live, and I want to upgrade. But without leaving the custom features behind.

Keep reading, this is a general software management question, not an SMF support question...

I'm trying to figure out the best way to port the custom features into the new code branch.

  • In some cases, the custom 1.1.x functionality will already exist in 2.0. Yay, no work for me!
  • In some cases, there will be mod packages versioned for 2.0, and I can just install them directly on a clean SMF 2 build. Yay, minimal work for me!
  • In some cases, the code port will be fairly straightforward between the two versions (e.g. a few small changes in queries or global variable construction). (I've ported a few features/mods back from 2.0 to 1.1.x, so I'm starting to get familiar with it.)
  • In some cases, I'm just going to have to redevelop the features mostly from scratch.

Those last two options are gonna be hard to manage.

Any suggestions on how to port a large number of changes from one branch to another? When it's not my own in-house code, that is. Here's my initial plan:

  • Diff between a clean version of 1.1.x and my "dirty" production code
  • Map each line diff to a feature ("That code update is the custom tagging feature, gonna have to port it line by line, and that one over there is the gallery, I can probably install an updated mod.") This would be SOMUCHEASIER if there were a diff tool that generated a consolidated report, instead of having to go through scores of files one at a time. Google and SO searches didn't find a tool like that-- Is there one?
  • Install a clean 2.0 branch
  • Install the available updated mods
  • Roll up my sleeves and go through my diffs feature by feature (this? is why I need the consolidated diff report. It would be hell to do page by page.) and build them back in.

Any better ideas? (Pointers to release management info are welcome, though of course with the caveat that it's not actually my code so I have limited control.)

Otherwise? I fear my options are ditch the custom features (not really feasible) or stay on the old branch. Both suck. Help!

tl;dr: Point me to a diff tool that will do consolidated file-by-file diff reports for entire directories. And/or help me figure out an easier way to migrate my custom code.

buzzo
  • 110
  • 7

1 Answers1

1

Your plan is generally the most practical approach, although I would say that you're heading in the wrong direction by looking for code-level differences. With no version control over the project lifetime and with no concise record of applied changes, in examining differences at the code level you are looking for a level of detail that may not give you the information you need to apply the same changes to a new implementation.

Move away from thinking of code-level changes and consider application-level feature and behavioural changes. What features have your changes introduced? In what ways does your application now behave differently due to your changes?

You say that there have been many unversioned changes over a long period - you will fail to find all the changes no matter what tools you have at your disposal and you will still need to consider the feature and behavioural changes that exist to fully represent the same features and behaviours in any upgraded implementation.

You know your application well, you use it and you do appreciate the feature changes that you have introduced even if you may not realise this.

  • Install a vanilla 2.0 release
  • Apply all appropriate mods
  • Apply relevant styling
  • Use the new system, note the differences in behaviour and develop from this a set of required features

Your feature set does not need to be complete - don't stall at the stage of trying to figure out all required changes, this will take too long.

  • Apply features gathered from most recent feedback (ideally through revertable mods)
  • Note the differences in behaviour at develop from this a set of required features
  • Repeat
Jon Cram
  • 16,609
  • 24
  • 76
  • 107
  • Thanks. I (think) I've got a pretty good feature-level list of features added to the old codebase. Or at least, that I could flesh it out pretty easily. You're right that the first thing I'll have to do is get familiar with the 2.0 codebase (and features!) to see what I even need to add on. I've started the code-level analysis like this: vanilla 1.0 release; put in version control; apply mods one at a time (ugh, time consuming! but necessary since I'm creating a new mirror server now anyway); then I should have a nice TortoiseSVN report between vanilla and custom modded 1.0. – buzzo May 24 '11 at 19:57
  • Then I can port the custom hacks, either all in one big port (sadly, my svn repository isn't as old as my hacks). THEN create a vanilla 2.0 install, play with it, list the feature delta, and look at what needs updating. Wow, I'm tired just thinking about it all. Good thing it's at least 6 months out! – buzzo May 24 '11 at 19:59