Problematic Current scenario :

I have coded around 4 websites. Every now and then when I want to make changes to the code, I first get all the files via ftp, the sqldb from working site, work on local machine, move everything back to server.

At times I also download the working version of the websites, all the files, and export the sql and save them on localmachine as backup. So i have tons of folders like, sitename-dateofdownload. I have reached to a point where its consuming tons of space on my local machine.

Ideal scenario:

Some sort of simplest version control, where all the files and sql get mirrored on my local machine with a few clicks I develop and test and once I commit changes, the original files and sql on the server are sort of backed up while my changes at local machine transfers to the server.

Sorry for being extremely newbie, I am sure experienced developers would understand what I am trying to ask. I would really appreciate if you could recommend the software + link to some sort of tutorial.

Thanks

Have you tried git? gitscm.org

_________________
Paid support
How to ask for help
1. Give details of your problem
2. Post any errors
3. Post relevant logs.
4. Don't hide details i.e. your domain, it just makes things harder
5. Be polite or you'll be eaten by a grue

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.)

_________________
rsk, providing useless advice on the Internet since 2005.

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

_________________
Paid support
How to ask for help
1. Give details of your problem
2. Post any errors
3. Post relevant logs.
4. Don't hide details i.e. your domain, it just makes things harder
5. Be polite or you'll be eaten by a grue

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...)

_________________
rsk, providing useless advice on the Internet since 2005.