Ben Collins-Sussman wrote:
>Wow, you've completely lost me.
>
>I read about your 'pain', and the thought that immediately occurred to
>me is: my gosh, why isn't the "live" web site also a working copy?
>That would fix all your problems.
>
>
The problem is, I'm working with multiple clients, who each host their
web sites on different web hosts. I generally have no logon access to
these servers, no ability to put a Subversion client up there to pull
down updates.
The pain is that my clients then update their web site directly, and
since it's not a working copy, I have to manually figure out what files
have changed to update my working copy, and export every time I'm ready
to post to a production server.
>For example, http://www.red-bean.com/sussman is my home page, and it's
>just an ordinary svn working copy. I make changes in my local working
>copy, and when I commit, a post-commit script on the server
>automatically runs 'svn up' on the live working copy. Instant publishing.
>
>
>
Yes, I do this for my internal web site, too. Works great. My public
site is hosted on a shared server (for bandwidth reasons, primarily),
though, with the same restrictions as my other clients.
>I don't see how that has anything to do with Kumaran's proposed
>feature. The existence of .svn/ directories in a live working copy is
>no big deal at all. Just add this to your httpd.conf:
>
>
>
The big deal is, it doubles the amount of disk space it consumes. That's
not a big deal on my own server, or on my desktop, but when my clients
are buying 50 MB of web space and using 30 of it, it seems wasteful to
make them upgrade simply because I want to make it work with
Subversion... not a particularly good sell to my client, either.
Now I'm just saying I'm interested in the patch, because it would
simplify a few issues I currently have worked out with tricks using find
and other scripts--there are certainly workarounds, and it's a great tool.
But I'm not a software developer--I'm a writer, consultant, and web
developer. I find myself spending a lot more time exporting from
Subversion to get a clean copy, than I ever do moving WCs around. It
would be great to be able to have my working copy be "pre-exported"...
Actually, I would probably keep the working copy on my dev server with
the .svn directories, so I could continue to mount those directories via
Samba and work on them directly from different machines, and then keep
an "exported" working copy separately, synchronized to the production
site. Come to think of it, this solves another niggling little issue in
my workflow--there's almost always one file I keep server-specific
details in for a given site. This contains database connection strings,
absolute paths to various resources, different things like that. With
this arrangement, my "exported" wc could have the correct version of
this file for the site, pulled from another branch in the repository,
and I wouldn't have to remember to fix this file before uploading....
Cheers,
John Locke
Freelock, LLC
http://freelock.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Aug 28 00:48:10 2003