Face
Well-known member
In the last post I defined version control as the means you use to keep versions of your add-on project under control. But what does version control actually bring to the table of add-on development? Why should you use it for something as small as e.g. a scenario add-on (ok, ok, there is another flame-war hidden in that).
Well, for starters there are some fancy marketing bulleting points to almost every "product" out there, like so:
Hm. All nice and sweet, just I don't give a dime on that for a small add-on. So why using such a surely bloated monstrosity for a one file project?
If you go by these points, there is no reason to use one (of these shiny FancySuperSafe(TM) ).
And you should not.
.
.
.
Because you are already using a super simple versioning system for your single file project. It is called "file system".
Now you might say that this is a cheap argument, that the "means" I used in my definition should have a defined start and end, that the file system is a much too generic tool to be called version control. But think about it. Think what you do intuitively when you create an add-on. I'm pretty sure it goes similar to this:
So lay back and try to see the bigger picture here. What this describes is a version control workflow, where you use your brain and the file system as tools. Your brain and the file system are the "means you use to keep versions of your add-on project under control".
This approach to version control has many advantages:
So it seems as if there is a dilemma: either you use the simple workflow above for fast, flexible and efficient version control, but you can only do so big a project; or you use the FancySuperSafe(TM) bloatware to setup a team system for a big project, but don't use it for small things, because otherwise you'd need a garyw to handle the servers in every team
. And - for Orbiter development - you deal (at most) with small teams, so bloatware doesn't make sense.
Luckily, this dilemma was already solved. Today's Distributed Version Control Systems (DVCS) are capable of handling both scenarios very well. In the next post, I'm going to demonstrate how the above workflow is processed with Mercurial, and in which way this is just as flexible as the brain&OS approach.
Well, for starters there are some fancy marketing bulleting points to almost every "product" out there, like so:
- Backup and Restore - With FancySuperSafe(TM) you can now create backups of your valuable assets, and restore them with a single click!
- Synchronization - Did your team ever suffer in Sneakers networks? Take FancySuperSafe(TM)! It'll solve all your problems of team communication and collaboration.
- Global Undo - Visual Studio's Undo is not good enough? FancySuperSafe(TM) is putting you even back where you had nothing at all!
- Tracing changes - Your FancySuperSafe(TM) is giving you the ability to have the information about what changed when how on your finger-tips. Buy now!
- Author Identification - hits the fan? Customer is flipping you the bird? Don't worry! With FancySuperSafe(TM), you always know who is to blame.
- Sandboxing - Only with FancySuperSafe(TM), you can hack away on your code alone, always having the reassuring knowledge of a safe haven to integrate it all back with your colleagues.
Hm. All nice and sweet, just I don't give a dime on that for a small add-on. So why using such a surely bloated monstrosity for a one file project?
If you go by these points, there is no reason to use one (of these shiny FancySuperSafe(TM) ).
And you should not.
.
.
.
Because you are already using a super simple versioning system for your single file project. It is called "file system".
Now you might say that this is a cheap argument, that the "means" I used in my definition should have a defined start and end, that the file system is a much too generic tool to be called version control. But think about it. Think what you do intuitively when you create an add-on. I'm pretty sure it goes similar to this:
- "Oh, doing this vessel/MFD/scenario/whatever could be a good idea".Opens Orbiter folder.
Browses to /orbitersdk/samples/ or /scenarios/ or /mysubfolderhere/ .
Starts copying in some examples.
Hacks around.
Renames things.
Goes back and forth from development environment to test in Orbiter. - "Cool, looks good! Let's publish it!"Makes a ZIP with all important files included.
Uploads it to OHM.
Posts a thread with "ZOMG must see my add-on". Or so. You get what I mean.
Keeps on adding new things.
Makes new ZIPs.
Updates the add-on on OHM.
Nicely maintained version snapshots, isn't it? Talk about "control"!
But wait, that's just the picture here. In reality, you'd have this on your drive:
Hm. Not so nice now. But let's go on... - "Dammit! I can hack on and on, and that stupid ADI-ball is still not working right! Yesterday it at least stayed put, I better use that code again."Makes a ZIP with current code - you never know.
Scrolls through the ZIPs in his backup folder, finds "yesterday" by date.
Unzips into parallel working folder.
Checks with "diff-tool" what is the difference between "yesterday" and now.
Swears around a bit due to file overwrites, missing files, superfluous files.
Identifies the better code.
Gets the working copy running again.
Hacks away.
Makes another ZIP with better version based on old code state.
Updates the add-on on OHM.
Yeah, you know it already... those helpful arrows are not there...
- O-F member finds a bug: "I hate to rain on the parade, but your vessel/MFD/scenario 1.2 does the CTD dance."Searches furiously for anything with the label "1.2".
"What frakin version is he talking about? Ah! I see... it is the text I posted on OHM 2 updates ago. Good that I keep a changelog file where I note down my arbitrary dotnumber versions so I can find them later."
Searches furiously through backup folder.
"Where is the ZIP! OMG, I hope I did not trash it. A, there it is, named 'myProject_10_20120507_2.zip'"
Unpacks it into parallel working folder.
Compares with current work.
Bug is still there. Tough luck!
Fixes bug, but can't release that code just yet. Current features are not ready yet.
"Hm. Let's just release it as 1.2.1. I'll put it into the backup as 'myproject_10_20120507_2_CTD_fixed', so I can find it later"
Uploads ZIP archive as attachment on O-F.
Posts "Bug fixed! Please try"
O-F member replies "Sorry, but..."
Rinse. Repeat.
So lay back and try to see the bigger picture here. What this describes is a version control workflow, where you use your brain and the file system as tools. Your brain and the file system are the "means you use to keep versions of your add-on project under control".
This approach to version control has many advantages:
- It is very flexible. Using ZIP archives (or folder copies), you can do as much as your file system allows you to do, and there is no regulation but the one your OS inflicts on you.
- At first, everything is local, only when you choose to publish will it be transfered to remote locations.
- The central point (OHM) is not something that is given by the system, it is a convention agreed upon by the community you work in.
- Instead of going through many complex dialogs/processes/forms (like you could bet on encountering in FancySuperSafe(TM) ), this workflow uses simple tools like ZIP and Windows Explorer
So it seems as if there is a dilemma: either you use the simple workflow above for fast, flexible and efficient version control, but you can only do so big a project; or you use the FancySuperSafe(TM) bloatware to setup a team system for a big project, but don't use it for small things, because otherwise you'd need a garyw to handle the servers in every team
. And - for Orbiter development - you deal (at most) with small teams, so bloatware doesn't make sense.Luckily, this dilemma was already solved. Today's Distributed Version Control Systems (DVCS) are capable of handling both scenarios very well. In the next post, I'm going to demonstrate how the above workflow is processed with Mercurial, and in which way this is just as flexible as the brain&OS approach.
