<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><BR><DIV><DIV>On 2007/03/29, at 22:27, Rob McBroom wrote:</DIV><BR class="Apple-interchange-newline"><BLOCKQUOTE type="cite"><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Yes, this is exactly the process I follow. The issue here is that the "test" part can't happen until the files on the web server have been updated. Ergo, Subversion is not the right way to update those files because that would put "checkin" before "test".</DIV></BLOCKQUOTE><BLOCKQUOTE type="cite"><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">To be more explicit, I keep the working copy on the web server rather than on my local machine and use some kind of remote filesystem to access it. I don't generally have local copies of any of these files. Perhaps that will clear up some confusion.</DIV></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Why don't you use rsync or scp for synchronization with your web server? Check-out, modify, sync, test, modify, sync, test, check-in. Then on production web server you just want to update.</DIV><BR><BLOCKQUOTE type="cite"><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">On Mar 29, 2007, at 4:38 PM, Charilaos Skiadas wrote:</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV> <BLOCKQUOTE type="cite"><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">2) I would think that it is particularly important that you have a subversion system exactly when you do web stuff, where you need to check things on the actual server often. With a subversion system, you can update the server after you've committed the changes, and then if there are problems simply revert to the previous, known-to-be-working, version until you've worked out what went wrong.</DIV> </BLOCKQUOTE><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">OK, but whether I commit my new crappy changes or not, the old "known good" version was previously committed and I can therefore revert to it, so I'm not sure what you're getting at. When I think changes are good, I commit them. If subsequent changes were a horrible mistake, I can revert. If I committed every single change, as you seem to be suggesting, then I could revert to previous good versions and previous bad versions, but why would I ever want to do the latter?</DIV></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>My personal opinion: just commit things that actually *work*. Never, but really, never commit undone things or things that fail compiling or stuff like that. If you are using Perl, first of all check if it don't have syntax errors :-D</DIV></DIV><BR><DIV> <SPAN class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Lucida Grande; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><DIV>--</DIV><DIV>Igor Sutton</DIV><DIV><A href="mailto:igor.sutton@gmail.com">igor.sutton@gmail.com</A></DIV><DIV><BR class="khtml-block-placeholder"></DIV><BR class="Apple-interchange-newline"></SPAN> </DIV><BR></BODY></HTML>