18/01/2006 @08:42:22 ^09:59:57
Shot in the face and you're to blame
You give multiplayer co-op a bad name
Poor man's version control
Yesterday I found out what "refactoring" means. This is one of those words that seem to turn up in every discussion about computer programming in which "professionals" participate. It seems like something you're supposed to know about but I didn't.
I found it means basically rewriting your functions so they're split up into different bits, cleaning up parts that are no longer used, etc. For example in Doom there's the face on the status bar. I'd like to put the code that works out which face to display into its own function so I can use it both on the status bar and on the fullscreen HUD in the corner (somebody had this idea on Doomworld and I liked it). This is "refactoring".
You do this kind of shit all the time, especially if like me you never design your code properly because you never did some knobby computer science course that taught you how to. But what's happened is, some gargantuan wanker's come along and invented a fancy term for it so he and his wanker buddies can make themselves look clever by using big words. "Agile programming methodologies", ugh.
Another thing is version control, or even more pretentiously, "Source Code Management". I started using svn last year because Prboom upstream does and I wanted the changes made to it since 2.2.6 was released. I decided to use it in which to keep my copy of the prboom source and my changes to it. Since doing so I have realised that all it is is a fancy way of doing something that I've done for years.
- checkout: Before you start making a change that you don't think will work out, or might break something significant, make a copy of the files you're going to change in a backup directory ("repository")
- revert: So your changes didn't work out? Oh well. Retrieve the files you backed up earlier and put them back in the main source directory.
- commit: There is no explicit commit operation other than deleting the backups you made earlier!
- merge: Obviously this was never needed with my own stuff but once or twice in the time I was working on DIY, a new version would come out upstream. That would require manual merging, where a file would either a) not be changed b) changed upstream c) changed by me or d) changed by both. All the cases were trivial except d) where you had to be a bit more careful. Fortunately somebody had ported GNU diff to RISC OS which made things easier.
My point is, don't get discouraged if you hear "industry professionals" talking bollocks you can't understand. Chances are they're talking about something perfectly simple that will arise naturally from your own tinkering, just they've been on fucking corporate wanker training programmes that give everything twattish names.
Incidentally if you've just committed something to svn and then decided it was wrong and don't want the mistake in your repository making you look bad, you can do this: go into the repository directory, edit db/current, change the first field - the latest revision number - from N to N-1, then delete db/revs/N and db/revprops/N. Your working directory will then disagree with the repository over valid version numbers; at this point it's probably easiest to check out a new one. Oh this shit probably only works with fsfs type repositories. I don't know about the older db type. They don't work over NFS, so I don't use them.
