I know netbeans syncs the original files once I save, but if there is a file changed externally is there a way for netbeans to recognize this and either tell me to re-sync it or automatically resync it with the new changes?
Here's what makes this behavior possible:
NetBeans 6.9 contains a feature that automatically looks for external changes to keep informations about files up-to-date. We have some reports that it can slow down NetBeans mainly, when an open project has many folders. When NetBeans find out that files were externally changed, it re-scans the files to keep data up-to-date that are used with features like code completion, navigation etc. Unfortunately the notification and following re-scanning can take some time and during this time many mentioned features are waiting for the finishing of scanning. There is option Enable auto-scanning of sources that can switch off this behavior. The option you can find it in Options dialog, Miscellaneous category and Files tab.
The default behavior is that NetBeans also looks for external changes when the main window gets focus. This is can be during developing a web application very often when user switches between browser and IDE. The mentioned option also switch this off.
When you switch off option Enable auto-scanning of sources you can still keep the information up-to-date, just invoke Scan for External Changes action from Sources menu manually.
(Here's the original article by Petr Pisl)
I find it counterproductive to leave this setting on, as sometimes auto-loading external changes to a file opened in the UI without asking for permission first can ruin your day when you're forced to make small local changes that you don't want replicated in your repository. I'm sure other people can think of more reasons to advocate for "warn before loading external changes" behavior to be implemented in NB. That is one of the reasons why I like Eclipse better sometimes.
Related
Occasionally, my fingers are faster then my brain and accidentally close views or windows of my development environment (which is Eclipse Kepler). I usually have two windows of Eclipse running side by side with individual views configured in both of them. Unfortunately, as soon as I (unintentionally) close a view/window, I have to set it up again. E.g. the build files in my Ant view get lost, I have to reopen files and so on...
Generally speaking, are there any plug-ins or options you can recommend that can help me backup and restore sessions? I'm aware of the "Save perspective" feature, but it barely meets my needs.
To be more precise:
Is there any feature to make Eclipse request my confirmation, before a (top-level Eclipse) window is closed? - I rarely do uncontrolled clicks twice :-)
Is there any plugin to save and restore my current views (incl. build files in Ant view)?
Is there any plugin to save a set of open files I'm currently working on? Would be neat, if I could open several files on a single click and get working right away. I'm thinking of a session management, where I can switch between several sets of open files.
Just in case none of the above is available and I messed up again, are there any files I can copy from one workspace to another to restore my Eclipse setup (windows/views)?
Any hints are welcome.
I'm using Mylyn 3.12 for the first time with Eclipse Kepler. I am using subversive to manage SVN connection for team.
I doing web development, so no Java projects here. I'm having the craziest situation where Mylyn is always adding three files to every task I create after I deactivate and then reactivate the task. It's almost as though there is a hidden editor with these files open. I have no idea where they might be coming from. Why on earth it chooses these three files is beyond me. If I delete one of the files, it still tries to add the file to the context, but the editor opens with file does not exist. When I "clear all" from the task context, stop the task, and reactivate, the files still appear! I even clear the invisible section as well.
Does anyone have any idea what might be linking these files to the context?
Also, I'm using the ColdFusion builder plugin, so I don't know if was related to that.
Ok, on a hunch while dissecting this issue, I decided to go through the "Window->Navigation->Switch to Editor" Each of my three files had it's own editor listed here! However, I found no way to actually get to these editors. So, whenever a task was created, it would simply copy open files from these hidden editors. So, I had two copies of each file open. I have no idea what is going on with my "shared area."
Again, the only way I could get to the hidden editors was the Window menu item, so it beats me if this is a bug or a feature. It almost seems like it was split editor view gone terribly wrong.
I have a lot of Eclipse run configurations that I frequently access during my daily work (things like doing a maven clean build for various projects, running a test gui, deploying apps etc etc). The Run Configurations Window (accessed via Run->Run Configurations) is reasonably good and supplies me with most of my needs, but:
I hate having to manually open it up every time I need to run something.
The window is modal and that I can't easily access other Eclipse features while editing a configuration.
It loses any filters that I have applied previously.
Is there a way to have this window fixed in a view that I can access at any time, and that it maintains my context? It really seems to me that this feature was designed with little regard for the "Eclipse way of doing things".
I know about setting configurations up as "favourites", but I have probably close to a hundred of these configurations, and the favourites menu is simply not designed for that amount.
I'm currently using subclipse with eclipse to connect my project to SVN. Due to management decisions we must use the lock-modify-unlock model instead of the standard SVN model. We are accomplishing this by adding the auto prop need-lock. Subclipse recognizes this and asks us to lock whenever we edit a file, which works but it rather annoying. Is there any configuration settings we can use to make it automatically take the lock for the file as long as it is not already locked (at that point it can pop up and bother us)?
No, there is no setting to bypass the dialog.
We are using Scott Hansleman's suggestion for multiple web.configs from his post here. The problem we have is that we have to check out the Web.Config. If we remove it from the project, when we publish, no web.config is pushed. So we need to remove the source control bindings just from the web.config, but leave it in the project, and have the rest of the project still held under source control.
The issue is that source control makes the file read only until you check it out. We need to be able ot overwrite it with the prebuild events, preferably without having to check it out. Is there a way to remove the bindings from that file only, and still leave it as part of the project?
Thanks.
By adding a new file to solution explorer, you will get the little plus sign indicating it is due to be added to source control. Then, right-click and choose "undo pending changes". This will cancel the add but leave the file in your project.
If that doesn't work I suggest one of the following methods:
Use the Attrib task from the MSBuild
Community Tasks project to remove
the read only flag.
Use the Exec
task in MSBuild to invoke
tf.exe and checkout the file.
You should leave the file in source control. Otherwise you'll run into several issues:
changes won't be versioned. 'nuf said.
it can't be branched or merged, even though web.config is one of the files that's most likely to vary between parallel dev/test/production environments
changes you make locally won't propagate to coworkers without manual workarounds
developers setting up an environment for the first time won't get the file at all
Team Builds won't contain the file, so neither will your deployments. (surely you're not deploying directly from the desktop?!)
Note that the state of individual files is stored entirely on the TFS server. ('tf properties' dumps this metadata if you're curious) Only projects & solutions have bindings actually written into the file. And even those are dummy entries that tell VS "don't worry about me, just ask TFSProvider, it'll know who I am and where I'm supposed to be." While there are many other quirks in the VS project system that give me endless headaches, in this case it's your friend. Don't circumvent it.
Best options:
Edit your build script to toggle the read-only attribute before/after modification. If you're using the "copyifnewer.bat" script from the linked blog post, it should literally be one extra line. Even if you want to keep things entirely declarative within the MSBuild makefile, it's barely any work with the help of 3rd party tasks.
Use the File -> Source Control -> Exclude feature. After applying this setting, the file remains under source control, but will no longer be subject to automatic checkouts/checkins by the active solution. In other words, you can edit the file locally to your heart's content without affecting anyone else, but if you want to commit (or shelve) your changes you'll need to do it from Source Control Explorer or the command line.
Option #1 has the advantage of being a very quick fix for your existing setup. The downside comes from maintaining several copies of web.config.* Same reason why copy/pasting code is bad: if you change one, you have to go change all the others -- or worse, forget and let them drift out of sync until strange bugs force you to revisit the issue. This could be improved by changing the process so that there's only 1 "master" web.config and the additional copies only contain differences (via a textual diff engine, XSLT transforms, programmatic manipulation in Powershell, etc). Of course, that's more work.
Option #2 avoids #1's problems with very little overhead. (the engineering process itself is unchanged; only difference is how the Visual Studio UI behaves) This advantage is critical if you make changes to web.config at all frequently. Downside is that there is no built-in way to track variations on the "master" file. If the only diffs are dirt simple, eg a connection string or two, you may find it easiest to stick with just one "master" and let people make ad hoc changes on their dev machines. There are even tools to do this for you, such as Web Deployment Projects (easy) and the IIS Deployment Tool (complex). In any case your actual deployment should be automated and source-controlled, of course! If heavier customizations are required than these tools are capable of, then you'll probably want the hybrid master + transform approach described earlier.
I recently ran into the issue and could not find a good solution. With a little trial and error I was able to figure this out myself.
This works on Visual Studio 2015. I tried to follow the answer above, but 2015 does not have an "Exclude From Source Control Option" I could find. It does have source control / project integration where if you delete the file from source control or the project, it will automatically be removed from both places. This integration is enforced when you have the solution containing the project open.
The problem is when using a web.template.config, web.config is really a build output and should not be in source control. However deleting the file entirely and removing it from the project causes problems because then the file is not part of the Build / Publish steps.
So the work around turns out to be simple:
Close the solution. File --> Close Solution.
In the Source Control Explorer Window, Delete the file.
Check in the Change.
Open your solution and you will see that the Config file remains in the project.
You may see the Triangle / Exclamation Mark Icon warning showing the the config file is not found.
Rebuild the project and click on the file.
The file should now show without the warning.
It should not have the padlock icon next to it. This indicates that it is not under version control.
I did some more checking and found the "Exclude From source Control" feature. The key is that you need to select the item in the Solution Explorer window before selecting the menu item:
Select the Web.config file in the "Solution Explorer".
In the menus select File -> source control -> advanced -> Exclude Web.config from Source Control.
You will now get a Red Circle / White Line icon.
This works if the file is NOT ALREADY in source control.
If the file IS ALREADY in source control you need to do the procedure above to remove it from source control without also deleting it from the project.