Where did my committed file go?

Question

I am trying to learn how to use subversion. On my mac os x server I have:

~/public_html (lots of files)

I also have /var/svn/myproject (this is the svn directory where I used svnadmin ~/public_html /var/svn/myproject)

On my MacBook Pro, I used svn checkout svn checkout svn://myserver/mysvnpath

It checks out the files.

I edit a file and put something simple in.

I commit and it gives no error and says I am at revision 2.

My question:

When I committed the updated file, where did it go on the server? I never see it changed in ~/public_html.

Where is my updated file on the server? I looked in the revision files and I can see 2 in revs has my change (which is just the addition of one line, phpinfo();).

Thank you for any help.

EDIT: based on comments I can see I really don't understand.

EDIT: I tried svn update in ~/public_html but my index.php file is never changed. Interestingly, I have another machine that I checked out the code and it shows the new revision (2). I just can't get it back into ~/public_html. If I have to manually copy it back to ~/public_html then how can I be sure the most current version is being used. What good is the repository at this point? I know it tracks changes but I want it to push out the latest version if I update my web directory on the server.

Answer 1

You would also need to run svn update on ~/public_html.

I believe that ~/public_html is at revision 1, and your macbook is at revision 2.

Answer 2

Same confusion I've seen quite a bit.

Your SVN (if it's an SVN server) (/var/svn/myproject) and your webserver (~/public_html) are completely separate and have no relation to each other. You will need to save/upload the file to the ~/public_html folder and also commit to the SVN (server). One is the webserver and the other is the SVN (server).

The general process I use when working is:

1. Checkout the repository to a local folder (not the webserver directory because you don't want people to be able to access .svn folders).
2. Edit the necessary files.
3. Upload, save or copy the file from your working directory to the web server. Test to ensure it works. (Some editors, such as Dreamweaver or PhpEd can save to both your working directory and also your webserver directory (FTP or otherwise) in one key short cut.)
4. Once you are okay with the changes, use your SVN commit process to put the changes into the SVN.

Repeat each time you make a set of changes, except for the checkout, you'll want to do an update incase you make changes else where or someone else did. (I do this process each time I working on a specific set of changes or a bug for a site so I can track the history of what I have done for each change.)

SVN (server) is only for tracking changes. It often runs as a module of a webserver, but has nothing to do with your actual webserer.

If you are confused by how this works, I would recommend purchasing an SVN service so you are less confused and they will deal with the setup of the SVN and it's related problems.

Edit If you want it to automatically post you never version to the webserver (not recommended) then you'll need to create a script to update every 15 minutes or so. This is really bad because your .svn folders will end up on the webserver directory. You need to do this manually every time you make a change or export the svn to that directory.

Answer 3

The Rev 2 files will be updated in /var/svn/myproject. In order for the changes to be reflected as well in ~/public_html, you will need to perform an SVN update on that directory, as it does not automatically do so, and will still be at revision 1, at least until you update it. You can automate this process with a cronjob, and I believe there is a way to detect when there is a new SVN commit, but I don't know if/what it is.

Answer 4

I think this SVN FAQ entry will help you: "I'm managing a website in my repository. How can I make the live site automatically update after every commit?":

This is done all the time, and is easily accomplished by adding a post-commit hook script to your repository. Read about hook scripts in Chapter 5 of the book. The basic idea is to make the "live site" just an ordinary working copy, and then have your post-commit hook script run 'svn update' on it.

In practice, there are a couple of things to watch out for. The server program performing the commit (svnserve or apache) is the same program that will be running the post-commit hook script. That means that this program must have proper permissions to update the working copy. In other words, the working copy must be owned by the same user that svnserve or apache runs as -- or at least the working copy must have appropriate permissions set.

If the server needs to update a working copy that it doesn't own (for example, user joe's ~/public_html/ area), one technique is create a +s binary program to run the update, since Unix won't allow scripts to run +s. Compile a tiny C program:

#include <stddef.h>
#include <stdlib.h>
#include <unistd.h> 
int main(void) 
{
   execl("/usr/local/bin/svn", "svn", "update", "/home/joe/public_html/",
         (const char *) NULL);  
   return(EXIT_FAILURE);
}

... and then chmod +s the binary, and make sure it's owned by user 'joe'. Then in the post-commit hook, add a line to run the binary.

If you have problems getting the hook to work, see "Why aren't my repository hooks working?".

Also, you'll probably want to prevent apache from exporting the .svn/ directories in the live working copy. Add this to your httpd.conf:

# Disallow browsing of Subversion working copy administrative dirs.
<DirectoryMatch "^/.*/\.svn/">
Order deny,allow
Deny from all

---

An alternative: You could use the in-place import. Look here how to do it.

Answer 5

There are 2 processes here you're trying to solve:

1. How to manage different people working on the same source code. You have set up a subversion server for this; developers check out the code on their local machine and commit their changes to it.

2. Deploying your changes to the live site. There are several ways to accomplish this, depending on factors like the level of Quality Assurance you need built into the system, the speed at which changes must be deployed, ... In any case, it's a best practice to set up a proper procedure for deployment. It can be done by making your web server's public_html directory a working copy and running 'svn update' there (either manually, scheduled or triggered from the post-commit hook). However I would invest a little more time in a real deployment script (using msbuild, nant, simply a .bat file, whichever works for you) that exports the sources (using 'svn export') and puts them at the right place.