What files can be safely removed from CDT project and workspace before archiving or saving in a source control system?
Having MSVC experience, I tried to remove Debug and Release directories, this was really bad idea :(
Are you using an Eclipse plug-in for your version control system of choice? They seem to take care of everything (at least in my experience with the CVS and Mercurial plugins). If not, you'll need to tell Eclipse to refresh pretty much your whole project whenever you've interacted with version control.
The contents of the Debug and Release directories should all be autogenerated. If they're not, something's wrong.
Rather than what you can delete, turn it around and consider what you need to keep:
.project, .cproject and (if it exists) .settings
Your source directories
Your include directories
Any other human-created files at the top level e.g. Changelog, documentation
It may also be worthwhile looking inside the .metadata directory in your workspace root; for example, any launch configurations you have created are stored by default in .metadata/.plugins/org.eclipse.debug.core/.launches/ . (Although I have seen them inside project directories from time to time.)
Related
I accidentally deleted a wrong file in Visual Studio 2019 before commiting the changes. I lost not a lot of work but I want to prevent this in future.
Can I setup VS 2019 somehow that files are not immediately deleted but kept in a cache for a while?
Supposedly there is already a backup folder which VS uses for deleted files, but this folder was empty in my case. And also the fact that VS moves files into the Windows bin doesn't help me because my repository is not on the system drive.
Do you know about any settings in VS or is there maybe an extension?
Not exactly what you are looking for but this extension could help you. It migth not prevent the deletion, but give you the opportunity to recover the code.
I haven`t tested it and I am also not sure if it will work with VS2019.
A visual source code plugin for maintaining local history of files.
Every time you modify a file, a copy of the old contents is kept in the local history. At any time, you can compare a file with any older version from the history. It can help you out when you change or delete a file by accident. The history can also help you out when your workspace has a catastrophic problem. Each file revision is stored in a separate file inside the .history folder of your workspace directory (you can also configure another location, see local-history.path).
https://marketplace.visualstudio.com/items?itemName=xyz.local-history
The answer here is to use a version control system (like git) and keep a full history of your project.
Even on simple personal projects it is worth doing.
I'm working on 2 different machines (home vs. work) and transfer the code via GitHub, which works nice, but I just ran into a machine dependency when I added this code to the gradle.properties file to fix a vexing OAuth issue for google sheets:
org.gradle.java.home=C:\Program Files\Java\jdk1.8.0_131
org.gradle.java.home=C:\Program Files\Java\jdk1.8.0_77
Now I have to toggle between the 2 lines to get Gradle to compile. Need to check if I still need it (since I got the keystore files etc. sorted out), but I also wonder whether there is an easy solution to make this work (e.g. something like ifdef).
Obviously, I could just change the directory name in one of the machines I guess, but still curious how to solve this within Studio.
Lets start with a quote from the Gradle docs:
org.gradle.java.home
Specifies the Java home for the Gradle build process. The value can be set to either a jdk or jre location, however, depending on what your build does, jdk is safer. A reasonable default is used if the setting is unspecified.
So, by default, you should not need this project property (thats what they are called in Gradle).
However, there can be reasons, that you need to specify the Java directory. For this specific project property, you can follow Ray Tayeks advice and use the JAVA_HOME environment variable (on both systems). But there is also another approach, which can be used for any project property (and also for so-called system properties):
gradle.properties files can be located at different locations of the file system. Your files are located in the project directory and, therefor, they are included in your VCS. You can use them / it for project-related properties. An additional location is in the Gradle user home directory, which is by default the .gradle folder in your personal folder. This folder is not under version control, so simply define the property there.
try removing the line from the properties file. if that fails, try setting JAVA_HOME on each machine.
there are a lot of related questions.
you might try asking on the gradle forums.
We have a Libraries folder where we keep third-party DLLs and our own utility DLLs for all applications to reference. I want to do development against one of our utility DLLs and an application that consumes it at the same time. But if I check out the library DLL to change it for temporary local use, TFS insists on checking it out exclusively, which trips other people up. I understand the reasoning behind it doing that (hard/impossible to merge a DLL, so two people shouldn't be working on one at the same time), but I just want to mess with my local copy while I'm working on the library it represents.
I suppose I could delete my application's reference to the DLL and recreate the reference pointing to some other place, but of course this just begs for me to forget and check it in like that, which would obviously be bad. Not to mention that this is a pain in the neck.
How should I proceed in such a situation?
You are using a server workspace that does not allow editing outwith TFS. In TFS 2012 local workspaces were introduced which do not have a read only flag for files and you are free to edit at will.
You can change your existing workspace in a few clicks: http://msdn.microsoft.com/en-us/library/bb892960.aspx
You could just go into the file system and mark the file as writeable. Once you are happy the binary is good you could check it out, copy the new version of the file over and check it back in again. TFS marks binary files like this as locked for good reason, as you can't merge them in the way you can with textual content.
The best approach would be to use a NuGet repository to manage your binary dependencies, instead of relying on binaries checked into source control.
It's very straightforward to add languages to an installshield project. My goal is to
make a modified English (0x0409.ini) with some of the strings modified, such as
However I have a team of people that would have to copy these files to a directory much like C:\Program Files (x86)\InstallShield\2012Spring\Support andC:\Program Files (x86)\InstallShield\2012Spring\redist\. This is even worse with the 10+ machines in the build farm that could potentially need this file. It's a non-starter. It's hacky to have modify the install of a tool to get it to use an unsupported language.
Is it possible to check the language file to SCM and have it reside in a subfolder of <ISProjectDir>?
I don't believe so. I think you'd have to set up a post-build step that would copy in a modified ini file.
You could set up one in installshield's UI but I don't know if that persists in a stand alone build.
I'm using netbeans and maven in my project and for JSF configuration files it generates some .NavData files.
This bothers me during backing up my project and also is inconvenient for versioning systems.
How can i configure to use another folder for these files, e.g. target would be awesome.
Any ideas?
Thx.
These files are generated by plugins or specific editors of the IDE (NetBeans or Eclipse for example). They starts with a . in order to be hidden in Linux file systems.
I am pretty sure that you cannot change the directory where they are located, so the best solution is to add them in the .cvsignore or .svnignore or .gitignore file (depending on which Version Control System you are using). So these files will ignored during the VCS synchronization.