Been working in C++ using Git (via SourceTree) for version control.
My .cpp files will randomly become seemingly corrupted when I pull the project as shown below:
Github still has the correct version of the file and even selecting the 'Open After' option in SourceTree shows me the file unaffected:
The fact that Git and Github both have no problem showing me the file suggests to me it's a Visual Studio issue but I don't know.
One thing to also note is that SourceTree can't seem to display some of my .cpp files, and just treats them like binary files (but I'm not sure if this is related or not):
It's not a massive issue since I can just copy the code from Github, but it happens almost every time I pull so it's rather annoying. Any help solving this would be massively appreciated.
No solution but things that you could check:
what is the version of git? Old versions <2.0 on Windows had a bug like that. Upgrade to the last versions that are quite good
verify that your files are encoded in utf8
that git don't touch you files when committing ('autocrlf' at false)
Related
I have been upgrading a project and since the latest version of Visual Studio 2019 was installed have found the following file being output to disk
MyProjectName.GeneratedMSBuildEditorConfig.editorconfig
I think that this is related to the roslyn compiler and was introduced in this commit: https://github.com/dotnet/roslyn/commit/de348c5a77977459a4138de0a62487e00980e28a#diff-e87b4990385fcfea8cf3f744bb8ad23e
The obvious questions have arisen as to what this file is, what it does and whether it should be in source control or excluded. I know what .editorconfig files are for but this one was unexpected. My searching has turned up nothing. Can anyone shed any light on this?
Update: This is fixed in Visual Studio 16.9 and higher.
There is a bug when using legacy/non SDK-style projects, which causes these files to be output to the wrong location. We have a fix out for this here: https://github.com/dotnet/roslyn/pull/48781
In the interim as a workaround you can set the generated file output path explicitly by adding the following to your project file
<PropertyGroup>
<GeneratedMSBuildEditorConfigFile>$(IntermediateOutputPath)\$(MSBuildProjectName).GeneratedMSBuildEditorConfig.editorconfig</GeneratedMSBuildEditorConfigFile>
</PropertyGroup>
The right pull request is this one -- it's built as a way for some MSBuild logic to pass values to certain Roslyn analyzers. This is internal implementation detail and shouldn't be checked in to source control.
I'm surprised you noticed this file though -- it should be generated into your obj\ directory, which you should already have excluded from source control and never really noticed in the first place. Did it get generated somewhere else?
What am I doing wrong?
1. I write some code in Qt Creator, it works.
2. I save all, copy the folder with all the files in it to another location for safekeeping.
3. Then I write more code. This additional code doesn't work and I've gone too far to undo it.
4. So I close Qt, delete that folder, move the earlier one back to where it was originally, and load the older version.
But Qt still gives me the same errors that the newer code gave me, and won't run. It seems to remember this newer (bad) code even though it no longer appears anywhere in Qt - and the problem persists over computer reboot. I feel I'm missing something very obvious, but Mr Google can't help at all.
Try Build->Rebuild all. Your IDE is probably caching some of the previous results for performance reasons. I had the problem once using Qt Creator, and it solved it for me.
Delete the build folder. All that the build system knows about is the built files being newer than your now even older sources*. So a build won't succeed since plenty of intermediate files are wrong.
By the way, you really should be using version control, not moving folder around. I suggest git via smartgit, but that's just my personal preference. It's effortless.
* A build system could remember the absolute timestamps of the source used in the build and rebuild if they change, not only if the sources are newer than the results.
I do a fair amount of personal development on my computer and have used TortoiseSVN (I'm on windows) for web projects, but haven't used any version control for other languages. Anyways, soon I will be starting a decent sized C++ project and was going to try using SVN for it.
For web development, I normally just used notepad++ and it was really easy to manage it with SVN (just commit the whole source folder). However, for this project I will be using an IDE (most likely Eclipse CDT or Visual Studio) and was wondering what the best practice is to manage all of the IDE, project, and binary files. My guess was to make the IDE project outside of the version control, and just point to all of the source files into the SVN so all of the build and project files aren't committed. This way the only files in the SVN would be the .cpp and .h files.
However, if I wanted to switch to a new branch, then I would need to update the location of all of the source and headers to the new folder which seems like it would be a huge hassle.
Whats the best way to handle this?
Thanks
Ok, it seem I misgot the aim of the question in the first round. Now I'm assuming what is asked really to what to put under source control and what not.
Well, naturally everything but temporary/transient files.
If you install GitExtensions, it right away has a feature to populate the .gitignore file. Certainly depending on language you adjust it. Sure, solution, project, make files belong under control. .USER files storing some IDE preferences do not. As both IDEs and source control is ubiquitously used the content is fairly separated for many years, and should be pretty obvious as you do it.
External dependencies normally also shall be in a repo, though choice shall be made in which one. Some store everything together, others keep one dependency repo, others separate repos per component -- all depends on actual components and workflow. And you can replace physical storage of deps by an info file with stable links to the used version. It may also be covered later on the first change in dependencies.
For Visual Studio, there is a plugin that manages your files for you. As long as the files are part of the project, then they will be put into source control by the plugin. See ankhsvn for plugin info. Note that the express versions of Visual Studio are not supported.
I am sure eclipse has a plugin for SVN as well.
I'd like my .exe to have access to a resource string with my svn version. I can type this in by hand, but I'd prefer an automated way to embed this at compile time. Is there any such capability in Visual Studio 2008?
I wanted a similar availability and found $Rev$ to be insufficient because it was only updated for a file if that file's revision was changed (which meant it would have to be edited and committed very time: not something I wanted to do.) Instead, I wanted something that was based on the repository's revision number.
For the project I'm working on now, I wrote a Perl script that runs svnversion -n from the top-most directory of my working copy and outputs the most recent revision information to a .h file (I actually compare it to a saved reversion in a non-versioned file in my working copy so that I'm not overwriting current revision information at every compile but whether you chose to do so is up to you.) This .h file (or a number of files if necessary, depending on your approach) is referenced both in my application code and in the resource files to get the information where I'd like it.
This script is run as a pre-build step so that everything is up-to-date before the build kicks off and the appropriate files are automatically rebuilt by your build tool.
How about using SubWCRev the command line tool that ships with TortoiseSVN. You create a template file with tokens in it like $WCREV$ $WCDATE$ etc. Then have a pre-build step that run SubWCRev on your template file to create the actual source file that is fed to the compiler.
You can get SVN to embed it for you, if that will solve the problem. See the $Rev$ keyword on that page.
Have a look at svn keyword substitution here. There is another SO question here which I found through google!
antik's solution is the one we use. Be careful of using environment variables, the .h file ensures you can have a dependency which will cause any files that need it to be recompiled when the svn rev number changes.
We are migrating our works repository so I want to do a cull of all the unreferenced files that exist in the source tree before moving it into the nice fresh (empty) repository.
So far I have gone through by hand and found all the unreferenced files that I know about but I want to find out if I have caught them all. One way would be to manually move the project file by file to a new folder and see what sticks when compiling. That will take all week, so I need an automated tool.
What do people suggest?
Clarifications:
1) It is C++.
2) The files are mixed. I am looking for files that have been superseded by others but have left to rot in the repository - for instance file_iter.h is not referenced by any other file in the program but remains in the repository just in case someone wants to compile a version from 1996! Now we are moving to a fresh repository we can safely junk all the files that are no longer used.
3) Lint only finds unused includes - not unused files (I have the 7.5 manual in front of me).
You've tagged this post with c++, so I'm assuming that's the language in question. If that's the only thing that's in the repository then it shouldn't be too hard to grep all files in the repository for each filename to give you a good starting point. If the repository contains other files (metadata, support files, resources, etc) then you're probably going to need to do it manually.
I can't offer an existing tool for it, but I would expect that you can get a lot of this information from you build tools (with some effort, probably). Typically you can at least let the build tool print the commands it would run, without actually running them. (E.g. the -n option of make and bjam does this.) From it you should be able to extract at least the used source files.
With the -MM of g++ you can get all the non-system header files for the given source files. The output is in the form of a make rule, but with some filtering this shouldn't be a problem.
I don't know if this helps; it's just what I would try in your situation.
You can actually do this indirectly with Lint by running a "whole project analysis" (in which all files are analysed together rather than individually).
Configure it to ignore everything but unreferenced variable/enum/function etc warnings and it should give you a reasonable indicator of where the deadwood lies without those issues being obscured by any others in the codebase.
A static source code analysis tool like lint might do the job. They will tell you if a piece of code will never be called.
Have you taken a look at Source-Navigator? It can be used as an IDE but I found to be very good at analyzing source code structure. For example, it can find out where and if a certain method is used in your source code.
I don't know if it's scriptable but it might be a good starting point for you.