On Thu, Sep 1, 2011 at 1:38 PM, Ryan Schmidt <
subversion-2011a_at_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.
Received on 2011-09-01 22:50:25 CEST