If I am working on a php site created using the 'sources on remote server' option, by default the IDE is set to automatically upload any files that I make changes to on save.
If I am working on a file (the IDE uses the local version which was downloaded last), and another person makes a change to the remote file directly on the server. When I save my local copy, netbeans will overwrite the changes that my coworker has done to the remote files without any warning or indication.
I have been forced to use a totally inferior (and non-open source) IDE for PHP development, because Netbeans does not first check to make sure it is overwriting the file safely. The IDE I use now, before uploading the file to the server on save, checks to make sure that the file on the server is not newer than when I first downloaded it. If it is, then a warning is issued and I can choose not to upload the file. I can then diff the file, and merge them appropriately.
I believe adding the same functionality to Netbeans would be trivial and possible to push in the *.1 update coming in a few months.
I would like to +1 this issue. Consider this scenario:
I use NetBeans to modify files on a remote development server because I do not have a PHP environment setup on my client computer.
On the remote development server, I am using SVN for this project.
In NetBeans, I open index.php, make modifications, save it..all is well.
Then, "Frank" makes changes to index.php, checks it in to SVN.
I then do a svn update on the remote server to receive his changes.
Back to NetBeans, I open index.php, make changes, and save.
At THIS point, NetBeans did not check the server to make sure it had the most recent copy of index.php, nor did it check to make sure index.php on the remote server was newer before saving.
I would go ahead and check in my changes.
Bam, all of Franks changes are gone since I overwrote an updated copy of index.php on the remote server, and then checked it in. No svn merge issues, no warnings, nothing. Everything, according to SVN is in order.
I would consider this issue a bug and not an enhancement.
(In reply to comment #2)
> I would consider this issue a bug and not an enhancement.
Sorry, definitely not. You are mixing SCM and ordinary (S)FTP client - sorry, this is definitely incorrect. Try to use any other (S)FTP client - will it prevent any file overwriting? I doubt...
Anyway, in NB 7.2 (RC1 available right now), there is Remote Synchronization  available.
That's great news about 7.2. I really appreciate that.
"Try to use any other (S)FTP client - will it
prevent any file overwriting? I doubt..."
You're comparing apples to oranges. I'm not talking about the SFTP client built into NetBeans, I'm talking about NetBeans the IDE/File Editor. Okay, let's do the same thing with another SFTP client (Transmit) and a simple text editor (BBEdit).
Let's skip to this step in my previous explanation:
I then do a svn update on the remote server to receive his changes.
Back to N̶e̶t̶B̶e̶a̶n̶s̶ Transmit, I open index.php (In BBedit), make changes, and save.
At that time I "OPEN" the file using my SFTP client, it pulls a new copy.
So, yes, my scenario works great with any SFTP client, but that's not what I was complaining about. I was complaining about the fact that, even if I close the File/Project/Application in NetBeans, and re-open a file that was modified on the remote file system, it does not pull in the new file. THAT is a a bug.
(In reply to comment #4)
> That's great news about 7.2. I really appreciate that.
> You're comparing apples to oranges.
I don't think so.
> I then do a svn update on the remote server to receive his changes.
> Back to N̶e̶t̶B̶e̶a̶n̶s̶ Transmit, I open index.php (In BBedit), make changes,
> and save.
> At that time I "OPEN" the file using my SFTP client, it pulls a new copy.
Since you are opening the _remote_ version/copy of the file, right? This cannot be done in NetBeans. In NetBeans, one _always_ works with _local_ versions/copies which can be eventually uploaded to a server. In other words, NetBeans _never_ edits any file "directly" on a server.
(In reply to comment #5)
> Since you are opening the _remote_ version/copy of the file, right? This cannot
> be done in NetBeans. In NetBeans, one _always_ works with _local_
> versions/copies which can be eventually uploaded to a server. In other words,
> NetBeans _never_ edits any file "directly" on a server.
Right, and that is the problem. That local copy can quickly and easily become stale. Other IDE's (eclipse) that deal with remote files check for changes on the remote file system to a file before opening for editing to prevent this.
It seems that NetBeans will periodically synchronize the files in a project..if only it would synchronize the file you are attempting to open, THAT would be a great fix.
(In reply to comment #6)
> Other IDE's (eclipse) that deal with remote files check for changes on
> the remote file system to a file before opening for editing to prevent this.
The difference is that NetBeans does not deal with _remote_ files but only with _local_ files, always. Currently, we do not have any support to edit remote files directly, sorry.
(In reply to comment #7)
> The difference is that NetBeans does not deal with _remote_ files but only with
> _local_ files, always. Currently, we do not have any support to edit remote
> files directly, sorry.
Okay, I'm tired of arguing. This will be my last comment:
NetBeans DOES in fact "deal with _remote_ files" hence:
->PHP Application from Remote Server
NetBeans will then download REMOTE FILES. When you save a change to the LOCAL cache, it automatically updates the REMOTE FILE (possibly overwritting newer files on the remote file system). NetBeans is creating a new feature to BETTER their support with "_remote_ files".
It's not perfect, but it's better.
Aptana, Fillezila and other FTP/SFTP clients are doing this: alert me when I am about to overwrite some changes in some files. Even better, Aptana downloads the file from FTP when I open it.
You should fix it.
I think the save on upload check box should at least have a little warning on it stating it will overwrite files on the server without checking for modifications. I think what could address the problem we have been having would be a "synchronize on save" feature...
More options would be:
-Have an option to create a .tmp file somewheres locally when overwriting a file server. With the .tmp file being the contents of what was on the server at the time of being overridden.
-Is it possible to include server file versions in the local history when overwriting?
Actually, we could use the current behaviour to facilitate this. Here's what happens now:
File receive OK.
No such file
File delete OK.
I appreciate that checking modified time on each file save would be quite slow, so a middle ground must be achieved. Personally, I would prefer to see files downloaded and placed in the local history, but upload on save is slow enough as it is, let's not add a download before upload on save!
The only way I've found around this problem is to use an sshfs mount and dev via that - it's quicker than upload on save (even with a remote server) but refreshing source indexes takes forever.
auto-update from the remote server is a very useful feature!!!
I have similar problem. Update the file on demand, before open it in the IDE is better than periodic synchronization. Of course this feature can lead to another error, when this file is modified by another user in the same time. In this case before saving the file on FTP, should be check that this file has not modified between last update. Both functions could be set independently in the project settings.
Sometime I have many files which I never open. Synchronization these files isn't make sense, until there is no need.
I vote +1 for this feature.
*** Bug 245899 has been marked as a duplicate of this bug. ***
+1 for remote fetch on file open or sync on particular file save (anything that prevents from blindly overwriting remote changes)
+1, must-have feature
+1, have wasted weeks full of work on total atleast
+1 if You went full on on this, check for changes, prompt maybe bring up diff screen , or just make a backup file, it would tahek You 6 hours and save us sometimes days of work. as of now I can't use netbeans on group projects...
+1 this is a MUST HAVE! Other IDEs like PHPStorm do that, too. It is so dangerous corruption remote code.
At least there is no option to just sync only the changed files since last sync!
It is clear that if firstname.lastname@example.org is denying the obvious, arguing with no point , and nobody has done anything about this issue in 6 years, it means nobody cares anymore.
That bug or feature (i don't mind how you call it) makes netbeans unusable in a real environment, even for a setup of just 2 developers (my case).
So it is a pity if netbeans , which used to be great dies because of these little things.
So sorry I will have to uninstall it, I loved it.
+1 hoping for this feature every release
+1 for this issue, Crazy that it lacks this basic need
It works as designed so it cannot be a defect, sorry. Please, do not change it.
Correct me if I'm wrong, but that's why the issue type is "enhancement".
(A different interpretation: if it works as designed, the design is flawed.)
Just happened again. It is not a bug, but it is definitely an inconvenience.
@Tomas Mysik, @email@example.com: Why not make Netbeans better?
+1 As many people have said, it is completely insane that NetBeans lacks this very basic feature. There should be an option that causes clicking on a file to get the file from the server, not from the local machine.