Help Me Organize My Code

Have you tried git? gitscm.org

Git is just about the /most/ complicated version control system out there, not counting some insane commercial creations.

With non-familiar-to-SCM devs, ease of start is very important - especially with those that are mostly "not liking these new fangled things that are just additional annoyance".

I've had best conversion success rate with Mercurial (http://mercurial.selenic.com/) - it has the softest entry curve, in my opinion.

As for the backups, consider rdiff-backup or something else rsync-based.

Schedule the database export first, then the backup run including your website files and the database dump. (gzip –rsyncable is pretty useful for the bigger DB export files, too.)

The basics of git aren't hard. Most people can get away with just push/pull, commit, checkout and branch.

@rsk:

(gzip –rsyncable is pretty useful for the bigger DB export files, too.)

Whoa! I've never heard of gzip –rsyncable and it doesn't seem to be in the gzip man page although it is an accepted option.

Surely it will only work where the uncompressed input doesn't change size? Surely that isn't too often?

The rsyncable option is not included in upstream, although many distributions include the patch.

As for how it works, imagine it this way. Normal gzip behavior is to use fixed-size blocks (not sure whether that's input or output), so if you make a change that affects the length of the input data, everything after that point in the output would be different because the block boundaries would shift relative to the input data. Suppose that instead, gzip started a new output block each time it encountered a newline in the input. This way, each line of a file would be compressed separately.

If you made a change to one line, or even added or removed lines, the output blocks generated for the preceding and following (unchanged) lines would be the same as before; only the block(s) that changed will be different. rsync is able to see that only part of the compressed file has changed.

The rsyncable patch magically sets the block boundaries to give a similar behavior. The details are certainly different (it doesn't reset at newlines, for example), but I don't understand the code enough to know exactly how it works. But in concept, that's what it does.

Honestly, all can I say is that size of the nightly rdiff increment for 500MB-after-gzipping and ever-growing database dump is on average a few MB.

And for historical reasons the dump is a single .sql file that has the most growing tables near the beginning and then about half way down, so the file size changes, and the old data inside is moved to different position every time.

(Guess I could change it to dump separate files but it works, and I can be sure the tables have been dumped together, so…)