This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
I have been using Netbeans for a few years now and believe a few simple (or so it seems) features could greatly improve the productivity of PHP users. First of call, some context. Let me explain the workflow of a very high number of web (mostly php) developpers. They have a LOT of projects to work with (we have more than a hundred). They work in small teams, about 2 - 5 persons. They have to perform frequent, small updates on many different projects each day. These projects are located on many different webservers, some that are in the control of the team, some that are not. Some that are version controlled, some that are not. This setup is very impractical if you want to have a local development environment. It is too time consuming to prepare hundreds of projects locally. Especially since the environment varies from one server to another (different PHP version, different OS, different packages, different permissions, etc). That's why they use the webserver on which the project resides as the working development environment. They download, update (if code versionning is available), modify the file and then upload all day long. When you are developping on a remote server (not a local webserver), you NEVER need to work on a local file. You always need to upload your changes as soon as possible on the server. No matter if you are using version control or not, each time you open a file, you need to make sure you have the latest version. Otherwise, you're likely to overwrite a newer version on the server. It is not practical to keep all your projects up to date all the time (via synchronisation), nor is it practical to re-download the whole project each time you need to make an update to it. Also, you cannot update (SVN UPDATE) your files without re-downloading them first, risking outdated files that will create conflicts. In an ideal world, netbeans would save the "last update timestamp" of the file when you download it. Then, when you upload it, Netbeans would check if the timestamp of the file on the server is newer than your local version. If it is, then it would give you a warning of some sort and you could take action. Ideally, you would be proposed a diff or something convenient to merge the changes. Also, it would be nice if there was an option to download the latest version of a file automatically when you open it, in order to prevent a manual operation that is performed hundreds of times a day. This doesn't affect code versionning, it is just a safeguard and a convenience tool. It would dramatically improve productivity and reduce greatly the quantity of "overwrite with a previous version" that occurs every day. So here's what I suggest: Most important : Save the timestamp of the file when downloading and check while uploading to prevent overwrites Important : Create a "download file on open" setting Just gravy : Diff/merge tool when a possible overwrite is detected
Has this request been placed at the right location? I was sort of expecting a follow up. I'll rephrase the request in case it is too long to read. - Save the server and timestamp of a file when downloading it. If the file is later uploaded on the same server, check the timestamp and make sure they match. If they don't give a warning. - Add the option to download a file automatically when you open it. Thank you.
(In reply to comment #1) > Has this request been placed at the right location? Yes, this is correct component and subcomponent. >I was sort of expecting a follow up. Sorry, too many bugs & enhancements :/ > - Save the server and timestamp of a file when downloading it. If the file is > later uploaded on the same server, check the timestamp and make sure they > match. If they don't give a warning. This should already work. > - Add the option to download a file automatically when you open it. Please, report just _one_ bug/enhancement in _one_ issue so it can be then easily tracked. Thanks.
> > - Save the server and timestamp of a file when downloading it. If the file is > > later uploaded on the same server, check the timestamp and make sure they > > match. If they don't give a warning. > This should already work. I just tested, and no warning is issued. Perhaps there's something I don't understand. Here's what I did: -Download a file from the server, using Netbeans's FTP -Update the file on the server, using an external SSH connection -Upload the file back on the server, using Netbeans's FTP Result: The changes made through SSH were overwritten and no warning was issued. I used: Product Version: NetBeans IDE 7.0 (Build 201104080000) Java: 1.6.0_26; Java HotSpot(TM) 64-Bit Server VM 20.1-b02 System: Windows 7 version 6.1 running on amd64; Cp1252; fr_CA (nb) > > - Add the option to download a file automatically when you open it. > Please, report just _one_ bug/enhancement in _one_ issue so it can be then easily tracked. Sorry, my mistake. Should I file a new issue regarding this second request?
(In reply to comment #3) > I just tested, and no warning is issued. Perhaps there's something I don't > understand. Sorry, I have overlooked "the warning". Well, this is not implemented and will not be - why? Because then we would need to store timestamps of _all_ files in a project (can be thousands of files, or even more). Moreover, timestamps are not reliable (especially for FTP, due different time zones etc.) and any SCM will do this for you (I think that any SCM is a must for any development, this would solve your problem in a proper way). What is now implemented is that the timestamp of last download/upload is stored and then it is used to preselect only newer files to be downloaded/uploaded. From the reasons above, I will close this issue as WONTFIX. Feel free to provide your comments. > Sorry, my mistake. Should I file a new issue regarding this second request? Yes, please, I will update the summary of this issue. Thanks.
I believe the crux of the issue has not been addressed. > any SCM will do this for you (I think that any SCM is a must for any > development, this would solve your problem in a proper way). In my first message, I specify that SCM is used but it is unable to help on this issue. The setup requires each member of the team to upload their changes to the same server. Even if a branch is used for every modification, the code will still get overwritten, without warning. Committing each file before uploading it is not a viable option either. The problem, as well as the solution resides with the ftp server. > Moreover, timestamps are not reliable (especially for FTP, due different time > zones etc.) True, but that does not matter in this situation. A different timestamp (earlier or later) means the remote file was touched and thus a warning should be issued. > Because then we would need to store timestamps of _all_ files in > a project (can be thousands of files, or even more). I don't know what kind of performance or space cost this would require, but unless it is huge, I can assure you that plenty of web developpers would gladly pay it. There are already some FTP options in the projects settings, perhaps add another one for this? This improvement alone would save so much headache and wasted time caused by code overwrites. This is a serious issue and I'm really hopeful that it won't be dismissed so quickly.
Based on the last comment, reopening... (In reply to comment #5) > I don't know what kind of performance or space cost this would require, but > unless it is huge, I can assure you that plenty of web developpers would gladly > pay it. There are already some FTP options in the projects settings, perhaps > add another one for this? Search our forum or this BugZilla for "slow scanning" (or similar) of PHP files - scanning is based on file timestamps and it simply takes time and this time is not small. > This improvement alone would save so much headache and wasted time caused by > code overwrites. This is a serious issue and I'm really hopeful that it won't > be dismissed so quickly. Our (S)FTP client is designed to be as minimal as possible and this is definitely something extra; but I will try to think about it and look at it if it will be doable. Thanks for reporting.
Have been thinking about this issue for a while. I'm not trying to tell you what to do or anything, but couldn't this feature use the local history? There's an entry created in the local history each time a file is downloaded. Could there be a way to save the server's timestamp (of the file's last update) as meta-data in the local history? That'd be pretty convenient, perhaps it could be used to determine if the file has been updated on the server without adding too much overhead.
I too would really like to see some improvements in this workflow being in a PHP programmer capacity. In our workflow we have some files that are updated by designers who do not work with a SCM. It would be a huge boon to us and maybe Mangol if we could simply mark some (or all) files to "download on open". This way we can be sure that at least when we started editing the file we had the latest revision. It should be a simple thing to do such as "Download on Open: " *.css;*.html;*.phtml; in the remote connection dialog. As Mangol suggests perhaps if the file is different than insert this revision into the local history so we can refer to a difference between this version and our last copy on disk. Obviously there are some things here that could be done to improve this, perhaps store and MD5 hash of the file size/timestamp, and compare that with our last download timestamp/size... so to compare these on open instead of download on open, but not every problem needs a perfect solution, just an adequate one. I also must pay my compliment, Netbeans is amazing software and has turned my slacker of a machine into a development speed demon no small feat for all it does do. -- Thank you.
I think there's more to it than just downloading the file on open. Presently, there's no way to know if you're going to crush the latest version of a file when uploading or crush your local changes when downloading. Another approach to this problem would be to create a new operation, let's call it FTP Sync. It would compare the local version with the remote version of a file. If the timestamps do not match, it should perform a diff. This could be performed by right-clicking on a file. Perhaps it could also become a set of options: FTP Sync on Upload, FTP Sync on download. I trust this would not incur much extra processing? This is a major issues for web developpers as countless hours are lost each month because of version overwrites. And Netbeans has the power to fix it all.
(In reply to comment #9) > Another approach to this problem would be to create a new operation, let's call > it FTP Sync. This is unlikely to be done, sorry. SCM solves this more than better. > This is a major issues for web developpers as countless hours are lost each > month because of version overwrites. And Netbeans has the power to fix it all. No. Only SCM can _reliably_ help you with this situation.
Agreeing with you about SCM and reliability, however that is not the issue here. Let me present the problem in a different light. Netbeans works wonderfully for projects that runs on your local computer. Seriously, it's great. When the projects are developped on a remote FTP servers, plenty of problems pops out. It seems like FTP support was added as an aftertought and there are workflow issues. We're proposing solutions to fix these workflow issues. I know they look similar to SCM issues but THEY ARE NOT. Many other IDEs have decided to taken on these issues and they have great results. However, I believe Netbeans is superior and I would truly hope that someone would take the time to understand the problem that "remote FTP" developpers have. It is real, it is serious and SCM cannot help us there. We use SVN and it helps us to recover the files that the IDE silently crushes with an older version. But wouldn't it be brilliant if the IDE could prevent some (or most) these accidents?
Perhaps an example would be appropriate: 1. I get the latest version of a file and work on it all morning. 2. Someone else gets the latest version of the file and start working on it. 3. I'm ready to test my changes by noon. 4. I upload it and BAM, I overwrite the other programmer's changes. Is there a way to prevent this? -If the other programmer committed his changes into SCM, an SVN UPDATE before uploading could work. -If the other programmer is still working on the file or has not yet committed the changes to SCM, then we cannot prevent it. This is less than great. The IDE could help prevent it: a simple timestamp check would do the trick.
(In reply to comment #12) > Is there a way to prevent this? Yes, as I'm saying all the time - SCM. > The IDE could help prevent it: a simple timestamp check would do the trick. And then what? Should we _really_ emulate any SCM and try to merge your files? I doubt, sorry.
> And then what? Should we _really_ emulate any SCM and try to merge your files? This raises another point. There is no way in Netbeans (unless you prove me wroing, which would be great) to merge a local and remote version of a file. We're blindly downloading or uploading. If we want to diff or merge, we need to make a copy of the local file and then download the remote file. Then merge/diff and delete the copy. Hardly efficient. > > Is there a way to prevent this? > Yes, as I'm saying all the time - SCM. I explained in the example how SCM was useless in this case. It can't reliably prevent the issue. Please do not state that it can. My basic argument is that Netbeans does not help "remote developers" at all. They are stuck with a slow, unintuitive, and error-prone workflow. I am pointing out the problems and proposing solutions but you don't seem to acknowledge that the problems even exist. Perhaps the Netbeans team does not want to support this kind of remote development. If that's the case, I can understand why the issues that I raise are promptly dismissed, but I can't stress out enough that a great number of developpers are forced to use this workflow. So many of us would be glad if you could consider it in a future release. On the other hand, if you accept the fact that programmers are using Netbeans to develop code on a remote server, why wouldn't you help them out? Tools like "Download on Open", "Diff/merge on remote server" and "Warning when overwriting a newer version of a file" would make a MAJOR difference.
Any chance to have Netbean's team vision on the "remote developpers" approach?
I am glad to see others with the same problems as us! I have been trying to put these problems in words, but mangol and anacreo sums it up nicely! We are programming through an FTP. Net beans could make our life much easier. The proposed solutions are great! Especially download on open. I explain another problem that is not mentionned: We have a big project with hundreds of thousands of files (images, media, etc) My colleague create a new file at root of the web site For me to see the file, I need to right-click on the "source files" and click download Netbeans will need to "process" the hundreds of thousands of file before showing the download dialog. It can take up to 10 to 15 minute. I hope netbean consider ftp developper in the future. It is very different from regular local developer.
(In reply to comment #16) > Netbeans will need to "process" the hundreds of thousands of file before > showing the download dialog. It can take up to 10 to 15 minute. Try NB 7.1, it downloads files "lazyly" (on demand) so the download dialog should be displayed very fast.
*** Bug 203969 has been marked as a duplicate of this bug. ***
Yes! It works for Netbeans 7.1. Thank you, I did not realize it. Kudos to Netbeans. How about the other propositions? Bug 203969 was a good proposition. I know you say we cannot do it because of SCM, but it is a different problem. SCM help fix code issues but not FTP issues. When developping on a FTP, you cannot see what is on the server. Sometime you write over code or your code get written over.
(In reply to comment #19) > Yes! It works for Netbeans 7.1. Thank you, I did not realize it. Kudos to > Netbeans. Thanks :) > When developping on a FTP, you cannot see what > is on the server. Sometime you write over code or your code get written over. And that is the reason why one really needs to use SCM as _nothing else_ can avoid overwriting changes of someone else (really, no FTP client can do so). Ideally, SCM should be used also for deployment (in other words, it should be installed on the server as well and should be used for updating the application; another benefit is that one can really easily rollback to any older revision if anything goes wrong).
> And that is the reason why one really needs to use SCM as _nothing else_ can > avoid overwriting changes of someone else (really, no FTP client can do so). > Ideally, SCM should be used also for deployment (in other words, it should be > installed on the server as well and should be used for updating the > application; another benefit is that one can really easily rollback to any > older revision if anything goes wrong). Hi Thomas, this is all true. However, when the DEVELOPMENT environment is on a remote server and it is common to all programmers and designers, we need the FTP client's (or the IDE's) help. Let's be clear, this is useful for changes that are "in progress" and not committed to SCM yet. P.S. Thank you Thomas for your time and your patience on this issue, I hope we can get to understand each other.
(In reply to comment #21) > However, when the DEVELOPMENT environment is on a > remote server and it is common to all programmers and designers, we need the > FTP client's (or the IDE's) help. Let's be clear, this is useful for changes > that are "in progress" and not committed to SCM yet. Hmm, very unfortunate, I would say :/ But obviously can happen (and can work, of course). > P.S. Thank you Thomas for your time and your patience on this issue, I hope we > can get to understand each other. Thanks for your kind words, I appreciate your patience and perfect comments but this is really not easily fixable, unfortunately. But I will try to do my best to support this workflow (for NetBeans 7.2 I hope but cannot promise anything, sorry).
> but this is really not easily fixable, unfortunately. But I will try to do my > best to support this workflow (for NetBeans 7.2 I hope but cannot promise > anything, sorry). Thank you, is what I was hoping for: to get this issue considered. This kind of remote development situation is pretty common for PHP programmers and it would make our lives easier if our IDE can give us a hand.
(In reply to comment #23) > > but this is really not easily fixable, unfortunately. But I will try to do my > > best to support this workflow (for NetBeans 7.2 I hope but cannot promise > > anything, sorry). > > Thank you, is what I was hoping for: to get this issue considered. This kind of > remote development situation is pretty common for PHP programmers and it would > make our lives easier if our IDE can give us a hand. I would really like to see this issue considered too. At present I frequently have to have a separate FTP application running along side Netbeans. Much better that it was all dealt with in on application.
(In reply to comment #24) > At present I frequently > have to have a separate FTP application running along side Netbeans. Why? Which FTP client takes care of synchronization? Or what is another FTP client good for? > Much better that it was all dealt with in on application. Again, please describe your scenario, it could help us to improve the current behaviour. Thanks.
Hi Of course I start from the premise that Netbeans is my favourite IDE and it is free so I very much appreciate the work that goes into it. My scenario is quite similar to that described by mangol. I also described it on the forum and in another bug http://netbeans.org/bugzilla/show_bug.cgi?id=203893. However the responses I got made me think that any such improvements were not likely to take place, for reasons that I didn't understand. It is reassuring to see a number of contributors to this thread who agree with the need for better FTP functionality. I certainly recognise and am frustrated by "a manual operation that is performed hundreds of times a day" and now I know I am not alone in this respect. I also recognise and agree with the following: "My basic argument is that Netbeans does not help "remote developers" ... ...Perhaps the Netbeans team does not want to support this kind of remote development. If that's the case, I can understand why the issues that I raise are promptly dismissed, but I can't stress out enough that a great number of developpers are forced to use this workflow. So many of us would be glad if you could consider it in a future release."
Created attachment 116202 [details] Testing PHP project Use it on your own risk (backup your data first etc.).
So, I have a prototype. How can one test it: - download development version of NetBeans [1] - replace this jar [2] with the one I attached a while ago - start NetBeans, open PHP project with remote configuration - right click the Source Files (it does not work anywhere else!) and select Synchronize WARNING: The functionality is not fully tested yet so use it on your own risk (backup your data first, do not use it on your prouction servers etc.). Also, it is very important to have a feedback from you since the synchronization is not part of NB 7.2 now; before it can be integrated, it must be confirmed that it works for you. Thanks. [1] http://bits.netbeans.org/download/trunk/nightly/latest/ [2] <netbeans>/php/modules/org-netbeans-modules-php-project.jar
Thank you Thomas for your work on this issue. Your prototype is great, this is precisely the kind of feature that we needed. I performed a few tests and it has been able to detect the changes made on either local or remote version of the files and allowed me to make sure that my both local and remote files were up to date. Even though we know that this technique is not 100% reliable, it definitely is efficient enough. I can confirm that this new feature will save us A LOT of time and make our life A LOT easier. Here are a few bugs that I encountered. Of course, it's expected in such an early version but I thought I would let you know: -Sometimes the remote version of the file is not available while performing a DIFF in the Synchronize dialog. The left side is blank with a message saying "<Content Not Available>". Even though the file exists both remotely and locally. -I encountered an exception while the Syncronize operation was checking the timestamps. This happened the second time that I performed the Synchronize operation on the project. The first time, it worked succesfully but each time after, I received the following exception: java.lang.NullPointerException at org.netbeans.modules.php.project.connections.sync.SyncItem.verifyChildrenOperation(SyncItem.java:381) at org.netbeans.modules.php.project.connections.sync.SyncItem.validate(SyncItem.java:240) at org.netbeans.modules.php.project.connections.sync.SyncItem.<init>(SyncItem.java:143) at org.netbeans.modules.php.project.connections.sync.SyncItems.add(SyncItems.java:67) at org.netbeans.modules.php.project.connections.sync.SyncController.pairItems(SyncController.java:225) at org.netbeans.modules.php.project.connections.sync.SyncController.fetchSyncItems(SyncController.java:127) at org.netbeans.modules.php.project.connections.sync.SyncController$1.run(SyncController.java:108) Caused: org.openide.util.RequestProcessor$SlowItem: task failed due to at org.openide.util.RequestProcessor.post(RequestProcessor.java:423) at org.netbeans.modules.php.project.connections.sync.SyncController.synchronize(SyncController.java:105) at org.netbeans.modules.php.project.ui.actions.SyncCommand.synchronize(SyncCommand.java:102) at org.netbeans.modules.php.project.ui.actions.SyncCommand$1.run(SyncCommand.java:93) at org.netbeans.modules.php.project.ui.actions.RemoteCommand$1.run(RemoteCommand.java:98) at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1411) [catch] at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:1991) So, this Synchronize concept is really helpful. Here are my suggestions for improving it even further: -I guess this has already been planned, but add the Synchronize feature to folders and files, not only the entire "Source Files" -Add an option to enable the automatic execution of this Synchronize operation before uploading or downloading. When working remotely, we usually upload/download only a single file or a small set of files, so this should not be excessively time consuming. Perhaps the dialog could appear only if there are "conflicts". This would be a lifesaver. Once again, thank you for taking time to take care of us, remote developpers.
(In reply to comment #29) > Thank you Thomas for your work on this issue. You are welcome. Your comments and your attitude convinced me of trying to solve this issue. > Your prototype is great, this is precisely the kind of feature that we needed. > I performed a few tests and it has been able to detect the changes made on > either local or remote version of the files and allowed me to make sure that my > both local and remote files were up to date. Even though we know that this > technique is not 100% reliable, it definitely is efficient enough. I can > confirm that this new feature will save us A LOT of time and make our life A > LOT easier. Thanks, that is exactly what I wanted to hear. > Here are a few bugs that I encountered. Of course, it's expected in such an > early version but I thought I would let you know: Definitely, we need to know all major bugs (since these can be stoppers for integrating to NB 7.2). > -Sometimes the remote version of the file is not available while performing a > DIFF in the Synchronize dialog. The left side is blank with a message saying > "<Content Not Available>". Even though the file exists both remotely and > locally. Is there any error in the IDE log (View > IDE Log)? Or in the Output window? This sounds like serious issue, it needs to be fixed (but I need to know tha cause or the steps to reproduce, of course). > -I encountered an exception Will have a look and fix. > -I guess this has already been planned, but add the Synchronize feature to > folders and files, not only the entire "Source Files" Unfortunately, not. This is not possible, sorry. The reason is, as I already explaied before, that all the timestamps of all the files would need to be remembered, moreover for all project's remote run configurations - this is not doable. Now, only one timestamp is remembered for each remote run configuration and we don't need to care about any file changes or solving "sync conflicts". > -Add an option to enable the automatic execution of this Synchronize operation > before uploading or downloading. When working remotely, we usually > upload/download only a single file or a small set of files, so this should not > be excessively time consuming. Perhaps the dialog could appear only if there > are "conflicts". This would be a lifesaver. Can you provide exact steps, please? Not sure that I understand what you mean exactly. > Once again, thank you for taking time to take care of us, remote developpers. Once again, you are welcome :)
Created attachment 116224 [details] PHP project with remote sync (NPE fixed)
Just uploaded new version (the reported NPE fixed), please, test it. Thanks.
Thanks for the new version, I have performed a few tests with it. I did not faced any NPE this time. > > -Sometimes the remote version of the file is not available while performing > > DIFF in the Synchronize dialog. The left side is blank with a message saying > > "<Content Not Available>". Even though the file exists both remotely and > > locally. > Is there any error in the IDE log (View > IDE Log)? Or in the Output window? > This sounds like serious issue, it needs to be fixed (but I need to know tha > cause or the steps to reproduce, of course). No errors are present in the IDE log. I believe this occurs when comparing a file with an file extension not recognized by Netbeans. It might not be an issue. > > -I guess this has already been planned, but add the Synchronize feature to > > folders and files, not only the entire "Source Files" > Unfortunately, not. This is not possible, sorry. The reason is, as I already > explaied before, that all the timestamps of all the files would need to be > remembered, moreover for all project's remote run configurations - this is not > doable. Now, only one timestamp is remembered for each remote run configuration > and we don't need to care about any file changes or solving "sync conflicts". That's very unfortunate. It would have been much more helpful to have the possibility of synchronizing a single folder or a single file. The entire "source files" is usually pretty big and is a bit inconvenient to synchronize many times per day. > > Add an option to enable the automatic execution of this Synchronize operatio > > before uploading or downloading. When working remotely, we usually > > upload/download only a single file or a small set of files, so this should n > > be excessively time consuming. Perhaps the dialog could appear only if there > > are "conflicts". This would be a lifesaver. > Can you provide exact steps, please? Not sure that I understand what you mean > exactly. I guess this becomes moot since it is not possible to synchronize single files. Nevertheless, let me explain what I meant. Create a checkbox, related to the each projet that would enable the following: -When working in the IDE and I download or upload a file -A synchronize operation would be performed on the file -If no timestamp mismatch is detected, proceed with the upload/download normally -If a timestamp mismatch is detected, show the synchronize dialog, listing the files selected for upload/download
(In reply to comment #33) > Thanks for the new version, I have performed a few tests with it. I did not > faced any NPE this time. Thanks for verification. > No errors are present in the IDE log. I believe this occurs when comparing a > file with an file extension not recognized by Netbeans. It might not be an > issue. Láďo, could you please test it? I will try to reproduce it as well. Perhaps it is for non-text files? The diff can only show content of known MIME types (these MIME types must be "text/*"). > That's very unfortunate. It would have been much more helpful to have the > possibility of synchronizing a single folder or a single file. The entire > "source files" is usually pretty big and is a bit inconvenient to synchronize > many times per day. I can (perhaps) imagine synchronization for single folder but definitely not for single file - the reason is still the same (not possible to remember all the timestamps). The only possibility here would be to allow "synchronization" of single files _without_ remembering the time of this synchronization. The possible problems are obvious - the "real" synchronization itself (invoked on Source Files folder) would know _nothing_ about these single-file synchronizations so these files would be marked unnecessarily for download, upload, perhaps even file conflicts could occur... I can try to do it and you can test it and let us know how it works. OK? > I guess this becomes moot since it is not possible to synchronize single files. > Nevertheless, let me explain what I meant. > Create a checkbox, related to the each projet that would enable the following: > -When working in the IDE and I download or upload a file > -A synchronize operation would be performed on the file > -If no timestamp mismatch is detected, proceed with the upload/download > normally > -If a timestamp mismatch is detected, show the synchronize dialog, listing the > files selected for upload/download I see; if the functionality for single-file synchronization (as described above) would be fine for you, then this could be perhaps implemented but it would likely take more time to implement so I'm not sure if we are able to do it for NB 7.2. Perhaps we could submit this later as an enhancement for NB 7.3 (or whatever version will come after NB 7.2)? Thanks.
Tomas, I'll start testing it today (and continue later this week) and try to reproduce the MIME type scenario.
> I can (perhaps) imagine synchronization for single folder but definitely not > for single file - the reason is still the same (not possible to remember all > the timestamps). Single folder synchronization would be a great improvement if it is realistically implementable. > The only possibility here would be to allow "synchronization" > of single files _without_ remembering the time of this synchronization. The > possible problems are obvious - the "real" synchronization itself (invoked on > Source Files folder) would know _nothing_ about these single-file > synchronizations so these files would be marked unnecessarily for download, > upload, perhaps even file conflicts could occur... I can try to do it and you > can test it and let us know how it works. OK? Great, let's try it out. I believe that it will sill be very helpful. > I see; if the functionality for single-file synchronization (as described > above) would be fine for you, then this could be perhaps implemented but it > would likely take more time to implement so I'm not sure if we are able to do > it for NB 7.2. Perhaps we could submit this later as an enhancement for NB 7.3 > (or whatever version will come after NB 7.2)? Seems perfectly appropriate to me.
Created attachment 116356 [details] log from Windows This exceptions is thrown on Windows every time I invoke Diff action in Synchronize dialog. Diff on non-textual file shows empty window as it should. I'll do more testing on Linux env later Product Version: NetBeans IDE Dev (Build 201203020400) Java: 1.7.0_03; Java HotSpot(TM) Client VM 22.1-b02 System: Windows XP version 5.1 running on x86; Cp1252; en_US
Created attachment 116423 [details] PHP project with remote sync (sync for single files added) The IAE fixed as well.
(In reply to comment #36) > Single folder synchronization would be a great improvement if it is > realistically implementable. Not for NB 7.2. Could be added for the next version (at least I hope so). > Great, let's try it out. I believe that it will sill be very helpful. It is there with all the disadvantages I wrote before (no timestamp remembering for single file synchronization so the default operatin can be completely wrong). Please notice that more files (not folders) can be selected at once. > Seems perfectly appropriate to me. Perfect, please, do not forget to report it later once remote synchronization is part of dev build (still not decided whether it will be for NB 7.2, we need feedback from more users so please help us if possible!). Thanks.
Excellent, I think this is already very helpful in it's current state. I will send it out to my team and have them comment it.
(In reply to comment #40) > Excellent, I think this is already very helpful in it's current state. I will > send it out to my team and have them comment it. That would be perfect. Thanks!
Created attachment 116436 [details] IDE log Tomasi, I'm testing it on Ubuntu & vsftpd server (localhost). Since I'm on localhost, I've created a symbolic link on "server side" (not in local files where the open project is stored) and then tried to synchronize Source Files. bug #1: The sym link is listed and operation is DELETE. bug #2: When I tried to actually confirm this action, exception was thrown
Another, not sure if realistic, case: bug #3: Again, ftp is running on localhost. When a file is copied into the server without being transferred via the ftp (I'm on localhost, so simply copy/paste in nautilus), it is also marked to DELETE. I don't know how possible is this in real environment but since it actually deletes files from server it worth mentioning
Láďo, please always provide information about local and remote versions of the file, e.g.: - local file - missing - remote file - present and newer than last synchronization and similar. For the bug #3 - the file is present on the server as well as on the local disk, right? Thanks.
Sorry for missing info. bug #1 and #2: - remote file - created sym link to fileA, fileA was on remote side - local file - fileA (same version like on server) exists (not the sym link) => Synchronize bug #3: - remote file - pasted fileB (not using ftp) - local file - fileB was not at the client side =>Synchronize Maybe the offered DELETE operation makes sense (and I can still change it in the dialog to whatever I want) but I would prefer to see some warning message "Unknown file found..." also (if it is possible)
Created attachment 116513 [details] NPE download Continuing... bug #4: Reproducible (3 of 3). - userA creates new local fileB (so it is not on server yet) - userA invokes synchronize and as an action for that fileB selects DOWNLOAD (non-sense nothing to download since the file exists locally only) => NPE (log attached). The same happens in opposite direction: - another userB uploads new remote file fileA - userA invokes synchronize, there is the new fileA listed (with blank field for local path, ok). UserA selects this fileA and choose UPLOAD => NPE 2 minor bugs/proposals: bug #5: Only column Remote Path is resizable in Synchronization dialog. Cursor near the end of column Local Path changes as it could be resized but it is not. Column Operation is also fixed (the entire text is visible in tooltip text only) bug #6: When there is a conflict with files, message "Synchronization not possible. Fix errors first". I would change the last sentence to "Resolve conflicts first" I'll test the multiple remote configuration scenario during weekend/monday
bug #5: Two users (simulated by 2 remote projects in NB). Both users are synchronized, userA removes file fileA from project (right click on file, delete). The file is deleted on server as it should be. UserB invokes synchronize directly on fileA => action should be DELETE, but Sync dialog shows only NOOP. When I press DIFF to see changes, it ends up with correct error msg that file cannot be downloaded. When userA invokes Synchronize on "Source files" node (instead of on the file itself), the proposed operation is correctly DELETE for fileA. Two servers case on the way...
(In reply to comment #47) > bug #5: > Two users (simulated by 2 remote projects in NB). Both users are synchronized, > userA removes file fileA from project (right click on file, delete). The file > is deleted on server as it should be. > > UserB invokes synchronize directly on fileA > > => action should be DELETE, but Sync dialog shows only NOOP. When I press DIFF > to see changes, it ends up with correct error msg that file cannot be > downloaded. > > When userA invokes Synchronize on "Source files" node (instead of on the file > itself), the proposed operation is correctly DELETE for fileA. > > > Two servers case on the way... should be #7 :)
The two connections case seems to work fine, different sync status is applied for each connection. No new possible bugs found except the reported ones. Right now I don't know what else could I test (I'll add comment if any problems occur)
Thanks a lot, Láďo! I will start fixing soon... Thanks.
(In reply to comment #45) > bug #3: > - remote file - pasted fileB (not using ftp) > - local file - fileB was not at the client side > =>Synchronize > > Maybe the offered DELETE operation makes sense (and I can still change it in > the dialog to whatever I want) but I would prefer to see some warning message > "Unknown file found..." also (if it is possible) It depends on the timestamp of last synchronization: (a) if it is newer than the file, it means that this file already was synchronized; and because the local file is not present, it means that it was deleted, (b) if it is older than the file, it means that thi file is not synchronized yet; and because the local file is not present, it means that it will be downloaded. Please verify that it works so, thanks.
(In reply to comment #51) > It depends on the timestamp of last synchronization: > ... Yes, it works (it was caused by the way the particular FTP server returns timestamps)
Created attachment 116712 [details] New version New version with bug fixes
Just uploaded a new version with bug fixes; please, give it a try. To all: next Thursday is the last day when this feature can be merged to NB 7.2 - so we need your feedback! Thanks.
all #1 - #7 fixed and working, thanks :)
Here's the feedback from my team. All of them appreciated the new feature and found it very useful. The most common comment was to find a way to suppress the report once the synchronization is completed, when not requested. Perhaps a checkbox on the synchronize window would be sufficient? If checked, display the report. If not, do not display it. And remember the state of the checkbox between synchronize operations. I'm still waiting for more comments.
(In reply to comment #56) > Here's the feedback from my team. All of them appreciated the new feature and > found it very useful. Thanks a lot! > The most common comment was to find a way to suppress the report once the > synchronization is completed, when not requested. Perhaps a checkbox on the > synchronize window would be sufficient? If checked, display the report. If not, > do not display it. And remember the state of the checkbox between synchronize > operations. You mean the very last dialog (with the progress bar)? This dialog itself must be there because there can be temporary files (as results of diff action) - these temp files are before uploading/downloading copied to the project (they replace the real project files) and therefore any changes to any files must be avoided. Or do you mean anything else? > I'm still waiting for more comments. Thanks.
I meant the "Summary" dialog. We perform the Synchronize operation very often, usually for a single file or a small set of files, so I guess trying to reduce the number of click is the key to efficiency. The summary dialog is convenient when there is a lot of files, but cumbersome when there is only one or a few. Perhaps figure a way to disable/enable it with a checkbox (that save it's state) or do not display it at all when there is only one file. Also, it would be nice if there was a way to auto-close the "synchronization" dialog (with the progress bar). That's one more click we would be saving.
Please, to avoid misunderstanding, provide a list with titles of the dialogs and suggested changes; I will then tell you whether they are doable or not. Thanks a lot.
You're right, let me clarify. "Summary" Dialog: -Choose to display or not this dialog with a checkbox (checkbox would be located on the "Remote Synchronization for ..." dialog, remember checkbox state) -Do not display when synchronizing only one file "Synchronization" Dialog: -Choose to auto-close this dialog upon completion with a checkbox, located on this same dialog (Synchronization).
Created attachment 116855 [details] New version with "views" (filters)
(In reply to comment #60) > "Summary" Dialog: > -Choose to display or not this dialog with a checkbox (checkbox would be > located on the "Remote Synchronization for ..." dialog, remember checkbox > state) The dialog is there to be clear that _all_ files will be synchronized and not only the visible ones - try the new version of the plugin, now it has filters for operations (so e.g. only downloads can be listed but this has _no_ impact on the synchronization itself, all the files are synchronized, always); However, I can add the checkbox there if you wish :) > -Do not display when synchronizing only one file Makes sense, will do that. > "Synchronization" Dialog: > -Choose to auto-close this dialog upon completion with a checkbox, located on > this same dialog (Synchronization). Again, makes sense, will do that. BTW the plugin I just attached is going to be merged for NB 7.2 if no stopper will be disovered. Thanks.
Branch merged, will be part of NB 7.2. If there are any show stoppers, this feature will be removed from NB 7.2 and readded in the next version of NB. I have changed UI a bit (toggle buttons replaced with checkboxes) and have added the checkboxes for autoclosing/skipping dialogs. From now, please, report all the issues you find as a new issue (against php/FTP Support). Thanks for your cooperation. http://hg.netbeans.org/web-main/rev/93066d5ca65b
Wonderful, many thanks to Thomas and Láďo for their work on this improvement.
(In reply to comment #64) > Wonderful, many thanks to Thomas and Láďo for their work on this improvement. You are welcome! (BTW we are Tomáš and Láďa but it doesn't matter ;)
verified Product Version: NetBeans IDE Dev (Build 201203220400) Java: 1.7.0; Java HotSpot(TM) 64-Bit Server VM 21.0-b17 System: Linux version 2.6.38-13-generic running on amd64; UTF-8; en_US (nb)