I'm using TotoiseSVN client and Assembla backend in a VS 2010 express project. We have issues with VS folders (or filters) dropping and files sometimes not being added to the project. I notice when I commit the .vcxproj and .vcxproj.filters files are never checked by default even though they should be changing. So I manually check them and told others to as well when they commit.
This can lead to issues if team member A checks out, only changes some code, while team member B has the project checked out and added files to the project. If team member B then commits BEFORE team member A, team member A's project file doesn't have the new files team member B added so now his project overwrites team members B's project file he checked in and now the new added files aren't in the project.
How do we get around this besides having amazing coordination?
CMake is perfect for this.
In case you haven't come across CMake, it allows you to create your entire project's build files in a separate directory to your source files, outside of svn altogether.
A single CMakeLists.txt file in your repository's root would replace all your current .vcxproj and .filters files.
I suspect what may be happening here is that the developers aren't saving the project files when adding new files to them. VS2008 did this by default, but I think that in VS2010 they aren't saved until you explicitly do File -> Save All. As a result it means that the changes are not getting committed. Once your devs do get in the habit of saving the project files before committing then SVN will in 99% of the time handle all the merges for you. The remaining 1% of the time is when someone has done some more major restructuring of the project file or two people have made conflicting changes to the build settings. In these cases you'd have to resolve them by hand.
SVN will never overwrite one person's changes with another, it will always try to merge. So if you're running into this problem it suggests that one person is somehow rolling back someone else's changes, or they don't have the option in Visual Studio set to reload files when changed externally: Tools -> Options -> Documents -> Detect when file is changed outside the environment.
An effective way of dealing with this problem is to set up a simple build server, eg with Jenkins that kicks off a build periodically after there have been some checkins. If the build fails then the person who checked in gets a mail to tell them they broke the build. You can also have a monitor that shows the build status which makes broken builds more visible to the whole team and hopefully encourages everyone to keep the build fixed.
Related
We have a team of several members using Eclipse for a C & C++ application that we commit the make files it generates as part of the package build. I have added and committed a library to the project then we decide against using it. So I remove it from my project and commit the change to git for the rest of the team. When anyone else pulls the change their Eclipse reverts the removal to the .cproject file preventing the removal of the unwanted library, include paths, and toolchain paths. The only thing that seems to work is to blow away the project metadata and re-import the project, which is a hassle.
How do I easily get everyone else's Eclipse to accept the removal and stop adding it back in?
Thanks.
The issue comes from not committing the .metadata folder. Eclipse keeps a backup of the project somewhere in there and continually changes these file making it unreasonable to commit to source control.
The only thing I've found to always work is to delete the project from the workspace, but do not remove the files, and import the updated project after pulling the updates from source control.
You and your team may not be able or willing to do this, but it is easier to not check in IDE specific files at all and allow a build tool plugin like Maven or Gradle to handle the project structure and classpath. This is how I've worked with team members for years without experiencing this problem.
There is quite a bit of a paradigm shift doing this, and depending on the flexibility of your project it may not be feasible.
Edit:
I noticed you are of the C persuasion. I don't recommend Maven, but consider Gradle.
https://docs.gradle.org/3.5/userguide/native_software.html
So, we are in this process of migrating XAML Builds to vNext (2015) Builds on TFS, and we are trying to "do things as clean as possible", since we had many, many customizations on the XAML builds that could be avoided and actually gave us problems along the way.
One major issue we are facing is with paths and "global files". Let me explain:
There are some files that, for commodity reasons, we have on a single place and every SLN file on that Collection refers them. Those files are such ones as Code Analysis RuleSets, Signing Files (SNK), etc. So the change is made in one place only and it affects every build.
Well, in XAML Builds we have a Build that runs with CI that downloads (Gets) those files, and since we hammered-in the same exact pathing for TFS and Machine (with a environment variable for the beginning of the path), the path is the same on the Developers and Build machines. However, this creates dependencies between builds and workspace issues.
My question here is, is there a configuration that I am missing that allows referring to files in other branches other than the build one? Since I’m trying to keep the build machines as “disposable” as possible, it’s running with an Agent Config Out of the Box: No custom paths, no hardwiring.
I already tried referring the files directly with their source control path, for example. The only options I’m seeing are either creating a PowerShell/CMD Script that downloads those files right into the same folder as the SLN or keeping it “as it is” and use relative paths putting a “Build” Build Step before the actual Build Step so it downloads the files to the server.
Isn’t there an “Elegant” way of doing this? Or is our methodology wrong from the get go?
You can add a Copy Files step to copy the files that the build needs:
I'm on a BizTalk 2013 solution and I'm trying to grow into automated testing. However, when I try to run my tests after changing only the test project, or even just run the tests after changing nothing anywhere, I'm stuck building the same amount of projects that I build when I invoke a full rebuild on the project being tested. This eats up an enormous amount of time, and it's a death sentence for my ability to sell future investments into this type of thing.
Is this is a known deficiency with BizTalk, or with its interaction with MSBuild? Is it a known pitfall that I can repair on my end?
EDIT: After reviewing the "possible duplicate" thread, I believe this question to be similar, but distinct. The explanation from the thread highlights the mechanics by which MSBuild determines that a rebuild is necessary, but MSBuild is widely-used technology across all projects in Visual Studio and can differ significantly by project type based on that project type's specific targets import. I've edited the question title to reflect that I want to learn how to prevent this for BizTalk solutions rather than simply asking why it's happening (although knowing why is always helpful).
So, what you're seeing is not a problem with BizTalk (because BizTalk is perfect and wonderful and never has any problems ever...:).
It's actually a behavior of Visual Studio. To note, BizTalk Projects are just specialized c# Projects.
The best workaround, which I do all the time, is to uncheck the Build and Deploy options for Projects I'm not actively working with in the Solution Configuration. If the Project is not checked for Build, it will not build even when you choose Rebuild Solution.
One possible solution would be to reference not the projects, but the DLL files which are the result of the same - already compiled and built - projects.
This way, when building your test project, it would be built against these existing assemblies and hence would not take the time to rebuild those.
You have to make sure however that these DLLs are updated whenever the project behind them also updates. You could do this by rebuilding them, whenever necessary, in a separate Visual Studio instance.
It takes some practice and thinking to make sure you are building against the latest version, but it WILL save you a lot of time.
I've noticed this as well. Turning on diagnostic output on MSBuild, it turned out that the project settings .user files were being modified after the .pdb files. I've tried several ways of resolving this, including changing the modify date on the pdb file, setting the .user file to readonly, removing (renaming) the .user file, etc.
Unfortunately, the build task for BizTalk will overwrite/recreate/create new .user file after every build, and I haven't come up with a way to convince MSBuild that that it can just ignore the .user file being created as new. Due to that, I'd go with one of the other suggestions here.
Even creating an exclusive lock on the file so that MSBuild can't update it causes a rebuild, since then MSBuild thinks the build is dirty ("Project 'Schemas' is not up to date. Project dirty in MSBuild.")
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.
Is it possible to combine the following properties, and if so, how?
Store in our version control system some Visual Studio 2008 native C++ (VCPROJ) project files for the developers in our team that use this IDE.
Allow some of those developers to tweak their projects (e.g. using debug version of third-party libraries instead of the usual ones).
Make sure these modifications are done in files that are not versioned.
In other words, I would like to allow developers to tweak some settings in their projects without risking that these changes are committed.
An 'optional VSPROP' file approach seems doomed to fail, as VS2008 refuses to load projects that refer to non-existent VSPROP files...
Any other suggestion? Is this possible with VS2010?
You may not be able to do this but using a solution that generates the vcproj like CMake for example would let you do this. Scripts all your project with CMake and literally conditionally include a config file(if present for example) that developers can change on their setup.
Branches could solve this problem: you create a branch, play with different versions of third-party, merge changes to trunk if results are good.
Well, as a preliminary solution you could put the project file into something like .hgignore or .gitignore after its initial commit.
This way changes to it can't be done accidentally.
At least that's how I handle .hgignore itself.
We use a versionned "common_configuration" folder, and a script which copies project files from this "common_configuration" folder towards the "project" folder.
We have another script to copy the configuration backwards, so the developpers need to make a conscious action to commit their local changes to the global version control system.
It answers partly your needs :
The upside : we have a way to keep a common configuration for everyone, and no accidental committing of local configuration
The downside : blindly copying the files actually crushes local changes. We live with it. We could write some more clever merger tool (using diff, or xml specific manipulations), but don't want to spend to much time on supporting the deployment tools.