tomhudson's Journal: Simplist version control ...

But first ... considering it's in java, and java can be slooowwwww ... jedit actually runs faster than some editors done in badly-written c/c++ (I won't name the one I have in mind, except to say that like a lot of stuff written in Qt, it sucks. Note - this is NOT a reflection on Qt, but on stupid developers. You can misuse any toolkit).

With a few (very few) plug-ins added, open the files across 2 screens, 4 split windows in each, and it really does the job.

The things I *hate* about version control, esp. for small projects

1. You still need a check-in/check-out process. That sucks.
2. Backing up and moving to another machine requires that the other machine has access to the version control system, or that you install it locally.
3. If you want to run 5 different versions of your program at once, you need to have 5 different "sandboxes" to play in.

A better way, and it really works

I came up with a simpler system a couple of years ago. Totally portable, only needs the tools at hand (your editor), and lets you see at a glance which files are "stable" (don't change much over time) and which aren't. And it works with any language, both scripts and compiled.

I'll use my current project as an example. There's a php index file, some css files, and some javascript files.

The php file is named index.###.php, where ### is the current version. Every time I add, remove, or edit one or more files, that version number gets bumped (right now, it's index.147.php).

It includes code that lets me load specific versions of css, php and javascript files. For example:
includejs(127, 'digits, grid, title'); // js/digits.127.js, js/grid.127.js, js/title.127.js
includejs(132, "this"); // js/this.132.js
includejs(133, "rows, cols, stage"); // js/rows133.js, js/cols133.js, js/stage.133.js
includejs(142, "imgcache"); // js/imgcache.i42.js

If in version 148 I modify stage.js, I would create a new file called index.148.php, and make the following changes:

includejs(133, "rows, cols"); // stage.133.js is no longer included
includejs(148, "stage"); // uses the updated stage.js

Benefit 1 - every version is available for testing

I can immediately test any version w/o having to create a sandbox for it, just by clicking on the index file. No worrying that it will clobber my latest work. This means that I can quickly track down which version introduced a bug.

Benefit 2 - just by browsing the files, I can tell which versions need testing

Usually, when you introduce a bug, you have a hunch which files it might be in - is it the mouse-handling code, or the layout code, or the footer code ... if it's the footer (as an example), you might see that there are only 3 different footer.js files in the last week (110, 123, 125), so you only test those 3 versions, simply by clicking on index.110.php, index.123.php, and index.125.php. And, since all the versions are immediately available, there's no reason you can't visually "diff" any of them right in your editor.

Benefit 3 - portability

Just tarball the whole directory structure and you have everything needed to replicate it on any machine. No servers needed. No special tools needed. No special software to install. Also, makes backing up your project super-simple, so you're more likely to do it. Just tarball or zip the directories and email them to yourself, or ftp them to another machine, or drop them on a usb key :-)

Benefit 4 - de-cruftification

Too often, we leave files in a project because it's too much trouble to see if they're still being used. Looking at index.###.php tells you exactly which files are needed - no more, no less. Applying the same principle to, say, c or c++ just needs some careful planning on your part (in other words, don't be messy with your #includes).

Benefit 5 - no special training required

No need to remember the special commands for each version control system. Or with different versions of a particular version control system.

Benefit 6 - works easily with multiple developers

If Joe Blow and Mary Doe are both working on version 150, there's no reason they both can't work on their version of stage.150.js - they just need to "tag" the files - say, with their initials.

Joe Blow: stage.jb.150.js
Mary Doe: stage.md.150.js

They would both also create their own "tagged" index file - index.jb.150.php and index.md.150.php respectively.

Joe Blow would have something like includejs(150, 'stage.jb'), while Mary Dow would use includejs(150, 'stage.md');

One of them can then do a manual merge by creating stage.150.js and index.150.js, with includejs(150, 'stage');

Benefit 7: No having to worry about cache pollution

We've all been there - we edit a css or javascript file, and we don't see the changes in our browser because we didn't change the file name, so instead of reloading the file, it reads the outdated version from its' cache. With every changed file having a version number, you won't worry that you're being served a stale file. This can be a real time-saver.

This technique isn't limited to code - you can also use it for images (again, avoiding the cache problem).

Benefit 8: Re-basing is dirt simple

You find that you went down the wrong road starting at version 35, and now you're at version 57? No problem - just open index.34.php, and save it as index.58.php, and you're done. You have all the code available for the "bad" versions, so if there's some good stuff in a file that you don't want to lose (for example, icons.52.js, just change the includes to include that version. No throwing the baby out with the bath water ...

Benefit 9 - tracking between projects is improved.

If you find that you want to re-use a file (say mouse.130.js) in another project, just use it with it's original version number - mouse.130.js. Your main file might be at version 5 - don't change mouse.130.js to mouse.5.js. The idea is that, if at some future date, you update mouse.130.js in your new project, THEN you can change the version number. Also, if at some future date, you update mouse.130.js in the original project, you can do a simple fgrep of your projects directory to find every project that uses mouse.130.js, and decide if you want to update them on a case-by-case basis.

Benefit 10 - self-documenting life cycle history

You can see at a glance which files are "mature" - they have comparatively old version numbers - and which files are "unstable" - lots of recent versions. This isn't just a help in debugging (the less stable files are more likely to have bugs in them), but also for when you want to extract a file for use as a library routine - stable files are better candidates. If you haven't changed imgcache.js in 100 versions, it's probably a better candidate than, say, toolbar, if toolbar has 20 different versions in the last 50.

The only real problem is getting into the habit of, when everything is working good for a version, immediately saving the main file (index.###.php) as the next version, and then, whenever you go to edit a file, BEFORE your edit it, bump it up to the current version. Once you get into that habit, the whole process is SUCH a time-saver.

One thing I also do is have a file called changelog.###.txt (where ### changes with each version). I just add my latest changes to the top - this way, I can open, say, changelog.140.txt and changelog.150.txt, and the latest changes for both are right at the top - no scrolling. It's handy to just be able to type head -n10 changelog.???.txt if you're lazy - and any really good programmer should find ways to accommodate their inner lazy child.

We should be using version control - but we often don't because it is a bit of a PITA. This is dirt simple - a file browser and a text editor are all you need (and when you get down to it, the file browser is optional).

Re:

[tomhudson]

There's that - but there's also the simple fact that it really does work, and it greatly speeds up workflow compared to when I was using stuff like svn. And backups are SO easy that they get done!

It just *seems to be "too simple to be useful."

Re:

[tomhudson]

As for controls, let the file system handle it. Users can't overwrite each others files, so it's only the merges that are a problem, and they should be handled by one person anyways (at least for specific areas of responsibility) - and this can also be enforced at the filesystem level.

And when it comes to portable backups, there's not much faster than right-click on a folder, compress it, and copy it to a usb stick, to back up everything portably. How much time would it take to set up a second git repo?