Version control - decentralized repository
 

I'm not too familiar with version control, but as far as I can tell, everything (CVS and subversion) use a "centralized" repository. Is there any way that I can setup version control that:

1) can use multiple paths on the machine
and
2) can be read from normally, not through the revision control system?

What I want to do is implement revision control (like CVS) on the /srv/www/htdocs directory, the users' home /public_html directories, and a few other random directories. I don't mind having to check something out to work on it and then check it back in, but it has to be able to have Apache serve the files normally from those directories.

Also, I do a lot of development remotely and SFTP in the finished documents, so something that could somehow work with that (even if it's just a shell script to check in the documents from a temporary directory to the main one) would be great.

Any suggestions?

Sourceforge and friends use Web-based CVS viewers. The major problem with the kind of thing you may be asking is the massive amounts of metadata stored for all the files.

You may find TLA aka Arch to be what you want, about the decentrilization thing.

Hi -

Personally, I've had considerable luck with CVS (specifically, with WinCVS) in what I suspect is pretty much your scenario.

You definitely owe it to yourself to check out common alternatives like Subversion, RCS, Git and Visual SourceSafe and PVCS.

'Hope that helps .. PSM

PS:
Last time I looked, researching into MS-VSS is time particularly well-spent.

Why?

Because MS-VSS was (still is?) so BAD, so laughably inadequate, that it makes ANYTHING you decide on look that much better ;-)!

PPS:
MS-Sharepoint is another Lol joke when it comes to collaborative Content Management/Project Management. Check it out ... and then compare it with something like Mambo or GForge.

Paul,

I've looked into all of those, and I use CVS at work.

The problem is that I want something that DOESN'T use a repository. I.e. I want it to function on any files that I tell it to, in any directory system-wide.

Think more in terms of revision control for plain-tetx documents as opposed to source.

Ok, I'm at loss... ALL the source I've ever written was plain-text,
and as far as directories goes, svn is brilliant at e.g. holding a
store of /etc for you.


Cheers,
Tink

you dont need it in plain text to serve it with apache. you can compile subversion with an apache module that will allow you to serve the repository on apache plainly. or you can go for a little more robust solution which is Trac and the like.. either way you can browse and view the repository from a web browser.. and compiling with apache also allows you to serve the repository across http without using the svn server.

and as far as having a repository that is stored in plain text, that creates the problem of someone possibly changing files randomly without any tracking being enforced. (you know, when someone submits broken code and does not want to get busted), i think you might be missing the point of revision control.. if someone can tamper with the repository, then you run the risk of corrupting it all..

and as Tinkster suggested, subversion will hold anything, not just plain text.

Well, I did a bit of research on my own, and it seems that RCS is the system for me.

As to missing the point of revision control - I understand the point, but there are different tools for different applications. This is being used on MY personal machine, nobody is going to submit anything.

RCS does what I want - I install it once, and I can use the same system to track changes to code in /home, changes to configuration files in /etc and changes to HTML and PHP documents in /srv/www.

It's relatively simple, the checkin commands are easy, and it doesn't have a central repository. And best of all, it stores ALL version-tracking information in a subdirectory (RCS) of the working directory, so it doesn't interfere at all with the working file itself.

Ex: All I needed to do is create a "RCS" directory in my public_html directory, then check-in all of the files I want RCS to control. I can keep track of versions and revert to any previous version, but Apache still serves the documents normally.

Thanks, Paul, for the suggestion of RCS.

oops, i read your statement about using VCS at work wrong, and thought thats what you were referring to.

good luck

Thanks to all who helped. I started using RCS two days ago and am hooked on it, to the point that I've started using it at work for minor revisions also.

All it requires is to create a "RCS" subdirectory where ever you want to use it.

mkdir RCS

to check in files (leaving the working copy in place but locking it)
ci -u filename

to check out the file (replace working copy with RCS version and then work on it)
co -l filename

that's it!