Source Control - what files should/shouldn't be stored in source control

[MarkusR]

Hey Guys,

It looks like I started a Version Control war here. Peace everyone
peace.

I couldn't care less about which Version Control system one uses. I
don't have a choice. Currently it is Star Team and next it will be MS
new VSS. Not my say.

The point of my question was what file extentions need to be checked
into source control so I can check them out on the build machine and
build.

One poster mentioned not checking in the .sln files (which I don't
quite understand since that is the project file isn't it and how would
one open and compile the project then? Rebuild the project from
scratch?

I think he also mentioned not checking in the .csproj. Aren't these
intragral parts of the project. Note. My typical project usually
contain a windows application program, a windows service and a setup
program. (GUI for testing, service for running on the server, and the
installation program). My common code for the GUI and service are in
one unit in a project common directory.

Markus_R2
(since there appears to be another Markus_R out there posting )

 

[Jon Skeet [C# MVP]]

It looks like I started a Version Control war here. Peace everyone
peace.

I couldn't care less about which Version Control system one uses. I
don't have a choice. Currently it is Star Team and next it will be MS
new VSS. Not my say.

The point of my question was what file extentions need to be checked
into source control so I can check them out on the build machine and
build.

One poster mentioned not checking in the .sln files (which I don't
quite understand since that is the project file isn't it and how would
one open and compile the project then? Rebuild the project from
scratch?

Well, without the .sln file I suspect you're okay *if* your projects
don't refer to each other. I'd suggest checking in the .sln files as
well though.

I think he also mentioned not checking in the .csproj. Aren't these
intragral parts of the project. Note. My typical project usually
contain a windows application program, a windows service and a setup
program. (GUI for testing, service for running on the server, and the
installation program). My common code for the GUI and service are in
one unit in a project common directory.

I don't think anyone suggested not checking in the .csproj files, but
the .csproj.user files, which give user-specific settings for the
project.

 

[Laurent Bugnion, GalaSoft]

Hi,

Well, without the .sln file I suspect you're okay *if* your projects
don't refer to each other. I'd suggest checking in the .sln files as
well though.

In my last project, we checked in a few SLN files together with the
other project files. The SLN files represented typical configurations
(for example, we had one SLN for everything, one for only the web server
part of the application, one for only reporting related stuff, etc...).

When we started working on the next version of the application, we tried
not checking in the SLN files. We thought it would be easier, no need to
maintain the SLN files if there are changes in the project. Well, it
worked in the beginning, but as soon as you start maintaining
(correcting bugs, implementing change requests), it becomes a nightmare.
Mostly the locally saved SLN files are either gone or don't work
anymore. We ended up re-checking SLN files in the source control tool,
and we will keep it this way.

HTH,
Laurent