The meaning of .vssscc .vspscc and .suo files.
Should .vssscc, .vspscc and .suo files be added to source Control?
The .vssscc and .vspscc should be added to source control and the .suo file should be excluded.
What is the easiest way to do this?
Use the "Add solution to source control" menu item.
What are these files?
The .vssscc file is referred to as the solution hint file. It has entries to help keep the solution in sync with source control.
The .vspscc file is referred to as the project hint file and it also helps to keep the project in sync with source control.
The .suo file stores user specific setting for Visual Studio. Since different team member can vary these settings it should not be checked in.
Showing posts with label Source Control. Show all posts
Showing posts with label Source Control. Show all posts
Monday, July 14, 2008
Saturday, June 14, 2008
Easy To Do Right, Hard To Do Wrong
Easy To Do Right, Hard To Do Wrong
Part of the reason that technology workers are compared to cats (managing developers is like herding cats) is a misunderstanding of how their work is structured.
Quite often rewards are given for doing the wrong thing and the right thing is punished.
Praise is given for pushing a release out before it is ready.
Even more praise is heaped upon them for fixing the bugs in the early release.
Yet more praise is layered on top for tracking down and fixing all the data corrupted by all the bugs that were in the early release.
And on and on.
As a manager of technology workers the goal is to put in structure so the easiest thing to do is the right thing. And it is at the same time hard to do the wrong thing.
Take the one two three combo of 'Source Control is Authoritative' and 'Daily Build' and 'Automated Builds'
By insisting that the only code that matters is the code in Source Control, you make it hard for developers to create local branches that are far out of date with the main branch.
The 'Daily Build' reinforces checking in often and verifying that all local dependencies are fixed.
The 'Automated Builds' make it easy to verify that the checkin have not broken the code.
Part of the reason that technology workers are compared to cats (managing developers is like herding cats) is a misunderstanding of how their work is structured.
Quite often rewards are given for doing the wrong thing and the right thing is punished.
Praise is given for pushing a release out before it is ready.
Even more praise is heaped upon them for fixing the bugs in the early release.
Yet more praise is layered on top for tracking down and fixing all the data corrupted by all the bugs that were in the early release.
And on and on.
As a manager of technology workers the goal is to put in structure so the easiest thing to do is the right thing. And it is at the same time hard to do the wrong thing.
Take the one two three combo of 'Source Control is Authoritative' and 'Daily Build' and 'Automated Builds'
By insisting that the only code that matters is the code in Source Control, you make it hard for developers to create local branches that are far out of date with the main branch.
The 'Daily Build' reinforces checking in often and verifying that all local dependencies are fixed.
The 'Automated Builds' make it easy to verify that the checkin have not broken the code.
Subscribe to:
Posts (Atom)