Some readers of this blog series might have googled for DVCS, and found one of the IMHO cutest arguments against using a DVCS:
Still, I've never seen him without this one here, have you?
But whatever...
I'm so bold now to proclaim that especially for the lonesome cowboy coder, a DVCS fits the needs. Let me show - as promised - what the last post's workflow looks like with a DVCS. Of course I'm using a specific one here, but at this point you can still substitute it with any other DVCS. The "D", however, is important.
You may remember from last time that the basic action in the workflow is the snapshotting of the project. Let's assume we are clever and hack together a small script that does that for us. Let's call it "commit".
Of course we could hard code "commit" to always zip together our complete Orbiter folder. But that would also zip up all those original Orbiter files, that we don't want to end up in our snapshot. So what to do?
Well, we could script "commit" in such a way that it reads a file with all the files we want to end up in the snapshot. We can then hand-edit this file to add new things to the snapshot. We could also create a script to add things to this file, let's call it "add".
Now we'd need a script to upload and download those ZIP archives to OHM. Sure we could use the browser, but let's just pretend our scripting language supports a HTML transfer easily, and creating such scripts is a piece of cake. So... I suggest we just call those scripts "push" for uploading to OHM, and "pull" for downloading something from OHM.
Yeah. Nice. Some scripts more for getting differences of two snapshots ("diff"), a small script for extracting a specific snapshot ("update"), and maybe something to tag a snapshot with a nice name ("tag"), and we are set.
So what do we have here? Don't be surprised now if I tell you we just created a very rough DVCS.
rlyflag:
We could polish the scripts now until all possible corner cases that might come up in our workflow are fixed, or we could just download such a bunch of scripts from somebody else who already thought similar about it. And there are many such men and women out there.
One of them is Matt Mackall, the creator of Mercurial(HG). BTW: the short form used for it is not an abbreviation, but the chemical symbol for Mercury(Hg).
Mercurial is written in Python, a scripting language. So you can indeed say that it is nothing but a bunch of scripts to do exactly what I have described above.
Of course it is doing it in a fast, efficient, <your_marketing_adverb> and convenient way. It takes care of differential ZIP creation, it takes care of the file "list", it takes care of the fancy arrows you've seen depicting the relation between archives before.
And it comes with a Windows-friendly GUI called TortoiseHg (well, actually it is the other way around: TortoiseHg comes with Mercurial included). From this tool I've taken screenshots to show you what the last post's workflow looks like with Mercurial.
Engage...
If you compare this here with what I've posted before, you can see some common aspects:
But there are also differences:
I hope I've made it clear now, that using a DVCS even as a single developer even in the smallest possible project is nothing else but using an automated form of what you'd do intuitively manually, anyway. So why making your life more complicated than necessary? It is not like a DVCS costs you huge amounts of money. It is not like a DVCS will need a dedicated server-machine and a home-network. It is not like you'd have to commit yourself to a cloud-based system like SourceForge or even Github or BitBucket.
No. All you have to do is downloading a ca. 25MB MSI, install it, and issue "hg init" every time you start coding.
Still, I've never seen him without this one here, have you?
But whatever...
I'm so bold now to proclaim that especially for the lonesome cowboy coder, a DVCS fits the needs. Let me show - as promised - what the last post's workflow looks like with a DVCS. Of course I'm using a specific one here, but at this point you can still substitute it with any other DVCS. The "D", however, is important.
You may remember from last time that the basic action in the workflow is the snapshotting of the project. Let's assume we are clever and hack together a small script that does that for us. Let's call it "commit".
Of course we could hard code "commit" to always zip together our complete Orbiter folder. But that would also zip up all those original Orbiter files, that we don't want to end up in our snapshot. So what to do?
Well, we could script "commit" in such a way that it reads a file with all the files we want to end up in the snapshot. We can then hand-edit this file to add new things to the snapshot. We could also create a script to add things to this file, let's call it "add".
Now we'd need a script to upload and download those ZIP archives to OHM. Sure we could use the browser, but let's just pretend our scripting language supports a HTML transfer easily, and creating such scripts is a piece of cake. So... I suggest we just call those scripts "push" for uploading to OHM, and "pull" for downloading something from OHM.
Yeah. Nice. Some scripts more for getting differences of two snapshots ("diff"), a small script for extracting a specific snapshot ("update"), and maybe something to tag a snapshot with a nice name ("tag"), and we are set.
So what do we have here? Don't be surprised now if I tell you we just created a very rough DVCS.
rlyflag:
We could polish the scripts now until all possible corner cases that might come up in our workflow are fixed, or we could just download such a bunch of scripts from somebody else who already thought similar about it. And there are many such men and women out there.
One of them is Matt Mackall, the creator of Mercurial(HG). BTW: the short form used for it is not an abbreviation, but the chemical symbol for Mercury(Hg).
Mercurial is written in Python, a scripting language. So you can indeed say that it is nothing but a bunch of scripts to do exactly what I have described above.
Of course it is doing it in a fast, efficient, <your_marketing_adverb> and convenient way. It takes care of differential ZIP creation, it takes care of the file "list", it takes care of the fancy arrows you've seen depicting the relation between archives before.
And it comes with a Windows-friendly GUI called TortoiseHg (well, actually it is the other way around: TortoiseHg comes with Mercurial included). From this tool I've taken screenshots to show you what the last post's workflow looks like with Mercurial.
Engage...
- "Oh, doing this vessel/MFD/scenario/whatever could be a good idea".Opens Orbiter folder.
Browses to /orbitersdk/samples/ or /scenarios/ or /mysubfolderhere/ .
Initializes repository.
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!"
"Hg adds" all important files.
"Hg commits" a version.
"Hg pushes" everything to remote location.
Posts a thread with "ZOMG must see my add-on".
Keeps on "hg adding" new things.
"Hg commits" new versions.
"Hg pushes" new versions to remote location.
In reality here, you'll also get the "arrows":
- "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."
Checks the log of commits and finds "yesterday" by date, or maybe even easier by means of the commit comment.
"Hg diffs" to current work. No need for safety points, no need for a second temporary folder. You could even use your favorite diff-tool here.
Identifies the better code.
"Hg commits" the current work as safe-point.
"Hg updates" to the better code. No swearing.
Hacks away.
"Hg commits" the better version based on old code state.
"Hg pushes" new versions to remote location.
Yeah, you know it already... those helpful "arrows" are STILL 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."
"Hg diffs" version "1.2" with current work. It was tagged "1.2", so no need for a change-log file or whatnot.
Bug is still there. Tough luck!
"Hg commits" current work
"Hg updates" to version "1.2"
Fixes bug. Current features are not ready yet, but they are not present in the 1.2 snapshot, anyway.
"Hm. Let's just release it as 1.2.1. I'll just commit and tag it here"
"Hg pushes" new versions to remote location.
Posts "Bug fixed! Please try"
O-F member replies "Sorry, but..."
Rinse. Repeat.
If you compare this here with what I've posted before, you can see some common aspects:
- Both are very flexible. You do not have to think ahead in order to lay out structures or anything. Under the hood, DVCS is a scripted snapshotting system to create compressed archives of a complete project at a given time.
- Everything is local at first. Only when YOU decide so, it will be transferred to a remote location.
- The central point is not something that is given by the system, it is a convention agreed upon by the community you work in. There is no server where you need to have contact to.
- Simple tools are used instead of complex setups. With the ZIP-method, you use Windows-Explorer... with HG, you can use Windows-Explorer, too.
But there are also differences:
- With DVCS, there is much more automation than manual work ("commit" vs. ZIP)
- With DVCS, the important "arrows" for understanding of snapshot relations are visible.
- With DVCS, the identification of a snapshot is not an archive file-name, but a hash-code. No need for a stable numbering scheme, the system is doing this for you.
- With DVCS, the style and completeness of system information (change-log, where the ZIPs are stored, how old versions are located, etc.) is always the same: the repository format.
I hope I've made it clear now, that using a DVCS even as a single developer even in the smallest possible project is nothing else but using an automated form of what you'd do intuitively manually, anyway. So why making your life more complicated than necessary? It is not like a DVCS costs you huge amounts of money. It is not like a DVCS will need a dedicated server-machine and a home-network. It is not like you'd have to commit yourself to a cloud-based system like SourceForge or even Github or BitBucket.
No. All you have to do is downloading a ca. 25MB MSI, install it, and issue "hg init" every time you start coding.