On Thu, Sep 1, 2011 at 1:38 PM, Ryan Schmidt < subversion-20...@ryandesign.com> wrote:
> On Sep 1, 2011, at 13:52, Geoff Hoffman wrote: > > > I thought I would send this to the list to see if others have experienced > similar issues; and as a warning to look out for this scenario. > > What this should serve as is a reminder to all developers to use "svn diff" > (or GUI equivalent) every time before you commit, to make sure the changes > you're about to commit are actually the ones you intended to make. I'm > almost certain your developer is overwriting a newer file with an older file > via his FTP client or IDE, and is not noticing because he's not checking the > diff. > > The trouble here is that, the IDE is pushing a new version back to the remote server where svn is running, which is where the changes are are being lost. I think a solution isn't possible. What needs to happen is that when you save a local version, the IDE should issue svn up on the remote server to check for conflicts but it can't because it has only an FTP connection available to it. Even if he logs in via SSH to the server and issues svn up on the remote files (getting -r 400 of x/y.php correctly on the remote box), the IDE with his changes to -r395 isn't smart enough to know that the file has changed remotely (although it should, IMO, download a tmp copy to check before ftp sync). There is most certainly a method to operate in this fashion safely, however it requires more manual steps to be followed meticulously. It's probably safe to say that creating and working on a "remote project" is best suited for a single developer (with svn running locally on the downloaded project files) versus running svn on the remote machine. We also had the idea to mount the project via Go -> Connect to Server... and use svn "locally" on /Volumes/devserver/project but this is untested.