good stand-alone svn client

Question

Hi -

I'm currently working with partner on a PHP project.

We both edit directly to a local server (all files are stored on the server, which is also running a WAMP stack). I'm looking for an SVN client that will monitor and save all changes to the htdocs folder, and will update a remote SVN repository, through the web.

It would be a great bonus if I could manipulate the SVN client through a web-interface.

For example, say I save file1.php to the server. It would update file1.php on the svn website. If I would suddenly discover that my latest revisions to the file are bad, I could head over to the server (or use some web interface from my computer), and replace file1.php with an older revision.

I don't want to just install an SVN server on our local machine because I would always like to have a copy saved remotely with the latest changes.

Any recommendations?

Answer 1

http://tortoisesvn.tigris.org/

Answer 2

If i'm getting this right your intention is to use SVN as a versioned, automatic backup system. If this is the case, the most straightforward thing would be to use a file monitoring tool then call the svn command-line client for changed files to commit them to SVN.

Answer 3

I do not know of any software to do this. It would probably not be hard to script this using the standard command line svn client. I.e. have a batch/shell script that runs regularly and checks in everything that has changed.

That said, I would very strongly advise against doing this!

The normal working model of source control is that everyone has a local copy to work in, then checks in their changes to a central repository.

The explicit manual checkin makes sure you only check in stuff that works (generally) and lets you give valuable checkin comments.

Then the server can be updated with a known good version from the source control repository.

It sounds like you are working on a production system. I'd strongly advise considering using a dev environment(s) and the above approach.

Answer 4

You might want to consider a distribute source code control solution (Bazaar, Git, Mercurial) for the scenario you propose, where you have two committers working against two codebases. You could then have local commits and push and pull the changes to the two destinations as appropriate.

But going to your immediate problem you might need some sort of utility that monitors file changes on both ends and then invokes the svn client command as appropriate as soon as it detects changes

Answer 5

I do not believe it's possible or so easy.

When you put a folder under SVN on the client a specific folder structure is created to keep track of what files are locked, changed and so on. Trying to update a server SVN folder without first checking out files or editing files without checking them out (like you want to do) is a BAD idea.

A scheduled job that collect your htdocs folder in a zip file, version it via filename and then upload it to some remote storage could be a easier and faster way to manage this.

Answer 6

I haven't tried it yet, but SVN-Monitor might be useful. You will need ToirtoiseSVN client mentioned above to work with it.

Answer 7

I haven't found any (I also had the same trouble).

We do this in 2 steps.

When I have to develop a part of software - I branch the trunk and modify it when the others do the same to complete their tasks. Then we merge the branches and test them. After testing trunk is being updated by that merged patch.

And finally cronjob (or manually) runs script which sets resource to maintainance mode, deletes htdocs and exports there new trunk and then chown/chmod everything as needed.

This script we can run any time from admin-panel, setting neccesary revision if we need to revert buggy changes quickly...

Answer 8

I don't know if maybe the svn post-commit hook might be of some use, given the right script? You could automatically deploy the changes from the current revision (i.e. the revision just created prior to calling the hook) to the production system. I think this is the sort of thing you are asking for?

I have to say that I agree with some of the other comments here about the inadvisable-ness of what you are proposing. I'd recommend a solution in which you manually initiate the deployment process and the source is then pulled from the repository.

Apologies if I have misunderstood.

Edit: having reread the question, I think you are looking for automated commits into the repository, not automated deployments out of it. As this is the case, the scheduled script solution proposed by others is the best approach I can think of also. +1 to those who suggested that.