> I think you've misinterpreted my problem; I probably didn't do a very
> good job explaining it. (Although, being able to isolate peoples
> mistakes is nice as well, so I'll look into your suggestion.)
> $ svn checkout http://example.org/svn/some-site
> $ emacs some-site/htdocs/index.php
> [make some changes]
> $ svn commit some-site/htdocs/index.php
> Now, in order to test/view/whatever, those changes, they need to some
> how get onto our development web server.
> One way for me to do this is to ssh into our development server and do
> a checkout. But it would become very frustrating to have to do this to
> fix and test every minor bugfix and spelling mistake. Also, I would
> like to avoid having to teach our designer to ssh in checkout changes.
> (There is no way she would be willing to do this for every change. As
> it is, she hates having to upload both an html and a css file.)
I didn't misinterpret your problem, however I did fail to explain how what I
was suggesting might help matters!
Depending on how your machines are set up, you can hopefully share each
developer's working copy between the development server and the client
machines (perhaps using Samba to export the developer's directory as a share
(either from the client machine to the dev server, or vice versa), or using
NFS (ditto), or by having the developers log in to the development machine).
Once you've done so, your web designer can simply save the html/css files on
the share, and immediately test them. (Of course you can't do this without
virtual servers or something similar, or everyone would clobber everyone
else's changes). Then, when she's happy, she can commit the changes.
This may or may not solve your problem - depending on your working
practices, you may still need to upload the committed changes to a
functioning server (in which case you're in the same situation as before,
but you may need to do it less often), or (given that you have a test
server) it may be sufficient to check the HEAD out to the test server every
Whether this is of any use to you depends a lot on the specifics of how your
team work; I use something similar myself, and it saves me a lot of time,
but I suspect your requirements are somewhat different :-)
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Tue Aug 3 18:03:48 2004