Forum Moderators: phranque
1) First of all, what is everybody's take on version control:
a)unnecessary
b)usefull
c)total requirement
2) Second of all, what is the solution for implementing version control on shared hosting (my host doesn't provide any and won't let me install).
a)deal with it, and use nothing
b)use a local program
c)change hosts
3)Third of all, what programs have you found effective/good
a)SubVersion
b)Something else...
If you know you can go back to a previous version at will it makes changes much less stressful. No need, ever, to try and keep old stuff in comments cluttering up the place just in case it is needed (or worse multiple versions of folders/files which is just asking for mistakes to happen. I've cleared up in such situations several times when my predecessor didn't believe in version control).
2) Depends on whether multiple people need to access it from multiple locations or not.
If only you, or a team on a single site, then set it up locally. You are, after all, testing locally before you upload changes to live aren't you?
3) If you have no specific requirements that it does not fulfil than Subversion will probably be adequate. I use it myself for my sites. I find the free GUI frontends to be adequate at best (on Linux) but they are sufficient for my needs.
I'm currently looking into Linux version control packages, as I want to move completely off of Windows (don't intend to install Vista...). I've used trusty (or crusty...) old SourceSafe for my own projects, though I've used PVCS, RCS, Clearcase on various contracts.
It doesn't belong on your production environment. Run it locally, and always create a label before deploying to your server, as doing so creates a "release".
With remote-mounting (sshfs under Linux, various FTP and sftp programs under windows) you can even use your version control package to deploy to your server. Once you have tested in a local environment and made a label, just point the version control package to your live server as a working directory, then "get" the label. No need to keep track of which files you've changed and then manually upload them.
That is, mount your server's file system as a drive letter or on a Linux mount point, and your version-control package will be none the wiser.
1) It is paramount!
2) Yes- what jtara says is good.
3) I use CVSNT. It lives on a dedicated PC for the job (although running it locally is fine) However, the aim here is for ASCII based files to live in it (i.e. code), not documents, binaries, MP3s and the like.
CVSNT is useful as we can have multiple branching, no corruption (yet), integration with Bugzilla and none of the problems with checking in/out as CVS works differently to MS VSS.
If I run Subversion or s/t similar locally as you suggest, then how can the client connect to the repo and commit changes?
If I run Subversion or s/t similar locally as you suggest, then how can the client connect to the repo and commit changes?
When we say "locally", of course, we don't necessarily mean "locally". :)
It's just that it doesn't need to (and probably shouldn't) run on your production web server(s).
If you have a need to have people checking-in remotely, then by all means install it on an Internet-accessible computer.
If you have a high-speed connection at your office or home, punch a hole in the firewall, set-up port-forwarding on your router, put a dynamic DNS solution in place if needed, and now you can have others access your version control system remotely. In most cases, there will be a low volume of access, so a home or office Internet connection will be more than sufficient.
