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

M

MarkusR

I am currently using StarTeam for my source control. (Will eventual
switch to whatever the latest Visual Source Safe is going to be
called).

With debug, installers, deploy and everything the project directory
structure is a mess of files and directories

What files should be in source control (All final builds willbe done on
anothe machine)?

I read that PDB and SUO files should not be checked it.

My typical structure is:

Main project dir -
common
data (test data not to be source controlled)
project
Setup
Debug
Release
Frm (GUI)
Bin
Debug
Obj
Debug
Refactor
TempPE
Properties
Svc (Service)
Bin
Debug
Obj
Debug
Refactor
TempPE
Properties

What directories/file extensions should be in source control and which
ones will be rebuilt? My build machine probably will not have the exact
some file paths.

-Markus_R
 
B

Bruce Wood

MarkusR said:
I am currently using StarTeam for my source control. (Will eventual
switch to whatever the latest Visual Source Safe is going to be
called).

With debug, installers, deploy and everything the project directory
structure is a mess of files and directories

What files should be in source control (All final builds willbe done on
anothe machine)?

I read that PDB and SUO files should not be checked it.

My typical structure is:

Main project dir -
common
data (test data not to be source controlled)
project
Setup
Debug
Release
Frm (GUI)
Bin
Debug
Obj
Debug
Refactor
TempPE
Properties
Svc (Service)
Bin
Debug
Obj
Debug
Refactor
TempPE
Properties

What directories/file extensions should be in source control and which
ones will be rebuilt? My build machine probably will not have the exact
some file paths.

-Markus_R

I do not check in .suo, .csproj.user, or any generated files (.exe,
..dll, .pdb, etc)

Also I usually don't check in .sln.

Unfortunately (in .NET 1.1), some wiseacre at Microsoft decided to
store "critical source control information" in the .suo file, or so the
error message says. Equally unfortunately, the .suo file apparently
contains hard-coded directory paths, so checking out code into a
different workspace doesn't play nice with Visual Studio.

I hope that this area improves with .NET 2.0. :)
 
R

Robbe Morris [C# MVP]

Those and anything under the /bin/debug and /bin/release folders


--
Robbe Morris - 2004-2006 Microsoft MVP C#
I've mapped the database to .NET class properties and methods to
implement an multi-layered object oriented environment for your
data access layer. Thus, you should rarely ever have to type the words
SqlCommand, SqlDataAdapter, or SqlConnection again.
http://www.eggheadcafe.com/articles/adonet_source_code_generator.asp
 
R

Robbe Morris [C# MVP]

Team Foundation Server is actually pretty nice. Pain
in the neck to install though.

http://www.eggheadcafe.com/articles/team_foundation_server.asp

I am forced to use Subversion at work. There is not
a day that goes by that I don't curse our former
CIO for forcing us to switch to Subversion.

That worthless Ankh for visual studio blows even worse.

God, I hate Subversion...

--
Robbe Morris - 2004-2006 Microsoft MVP C#
I've mapped the database to .NET class properties and methods to
implement an multi-layered object oriented environment for your
data access layer. Thus, you should rarely ever have to type the words
SqlCommand, SqlDataAdapter, or SqlConnection again.
http://www.eggheadcafe.com/articles/adonet_source_code_generator.asp
 
Y

Yury

We have started to use TFS since second beta. We were waiting
release... we hoped that it would be better. We were using TFS release
for 1 month.
It's big pain.
* Stupid concept of workspaces.
* Stupid merging/branching (noticed a lot of unnecessary
changes/conflicts).
* Not working off-line without stupid hacks.
* Really slow (studio hangs for a while before I can edit a file.)
* Can't do anything without studio...
* Stupid Shelving (it doesn't support merge back. Why we need it
without merge?)
* And can't rollback commit/changeset!!!! What they were thinking
about??? And after release they create "admin tool" for that....
Blah...

So we leave TFS as our bug tracking system and migrate our code back to
svn.

And don't use Ankh. Use TortoiseSVN.
 
B

Brian Gideon

I'll second Subversion. I just started playing around with it this
week. It's *way* better than VSS. And for those who thinks it's
difficult to use...I setup a Subversion server, repository, and the
TortoiseSVN client in about 15 minutes with zero prior knowledge of how
to use it.

Is there an explorer-like client for SVN?

Is there a web interface for SVN?

Brian
 
J

Jon Skeet [C# MVP]

Robbe Morris said:
Team Foundation Server is actually pretty nice. Pain
in the neck to install though.

http://www.eggheadcafe.com/articles/team_foundation_server.asp

Yes - but that's not the latest version of VSS. VSS still lives as a
product, unfortunately.
I am forced to use Subversion at work. There is not
a day that goes by that I don't curse our former
CIO for forcing us to switch to Subversion.

Interesting. We moved from VSS to SVN a while ago, and I absolutely
love it. There are some problems merging when someone has either
branched incorrectly or deleted then recreated files, but those issues
can always be worked around in my experience. The rest of the time SVN
works extremely well. What do you have against it?
That worthless Ankh for visual studio blows even worse.

Ah, now that I could understand. I haven't used Ankh myself - I use the
command line and TortoiseSVN when I'm on a Windows box, and Eclipse and
the command line on Linux.
 
Y

Yury

Jon said:
Interesting. We moved from VSS to SVN a while ago, and I absolutely
love it. There are some problems merging when someone has either
branched incorrectly or deleted then recreated files, but those issues
can always be worked around in my experience. The rest of the time SVN
works extremely well. What do you have against it?

didn't noticed any bugs with merging/branching
Ah, now that I could understand. I haven't used Ankh myself - I use the
command line and TortoiseSVN when I'm on a Windows box, and Eclipse and
the command line on Linux.

Jon, take a look at subclipse http://subclipse.tigris.org/
I know people who use it and like it a lot.
 
B

Brian Gideon

Mark,

Yeah, that's what I've been using. I was wondering if there were any
clients that didn't use explorer shell extensions. I didn't articulate
my question very well.

Brian
 
J

Jon Skeet [C# MVP]

Yury said:
didn't noticed any bugs with merging/branching

There are a couple of bugs which have been fixed by 1.4 (which we're
not using yet) but it's more that you can get yourself into awkward
situations if you're not careful. They're not bugs, just gotchas.
Jon, take a look at subclipse http://subclipse.tigris.org/
I know people who use it and like it a lot.

Oh absolutely. My point was that I don't need to use Ankh - sorry that
I wasn't clear on that front. (There's also Subversive, which I haven't
used, but which is providing good competition for Subclipse.)
 
M

MarkusR

So then I would check in the following(?):

proj\FormMain.Designer.cs
proj\FormMain.resx
proj\Program.cs
proj\FormMain.cs
proj\ProjectInstaller.cs
proj\ProjectInstaller.Designer.cs
proj\ProjectInstaller.resx

proj\obj\ <nothing>

proj\properties\AssemblyInfo.cs
proj\properties\licenses.licx
proj\properties\Resources.Designer.cs
proj\properties\Resources.resx
proj\properties\Settings.Designer.cs
proj\properties\Settings.settings

setup\ProjSetup.vdproj

-Markus
 
B

Brian Gideon

Markus,

I usually set it up like the following.

MyProduct\MyProduct.sln

MyProduct\Project1\Project1.csproj
MyProduct\Project1\File1.cs
MyProduct\Project1\File2.cs
MyProduct\Project1\FileN.cs

MyProduct\Project2\Project1.csproj
MyProduct\Project2\File1.cs
MyProduct\Project2\File2.cs
MyProduct\Project2\FileN.cs

MyProduct\ProjectN\ProjectN.csproj
MyProduct\ProjectN\File1.cs
MyProduct\ProjectN\File2.cs
MyProduct\ProjectN\FileN.cs

MyProduct\References\ThirdPartyAssembly1.dll
MyProduct\References\ThirdPartyAssembly2.dll
MyProduct\References\ThirdPartyAssemblyN.dll
MyProduct\References\SeperatelyVersionedAssembly1.dll
MyProduct\References\SeperatelyVersionedAssembly2.dll
MyProduct\References\SeperatelyVersionedAssemblyN.dll

Your product, whether shrink wrapped or in-house, should be completely
self-contained underneath one folder. There is a References folder
which contains all dependent third party assemblies and separately
versioned in-house assemblies. Projects that depend on each other use
a project reference while projects that depend on assemblies in the
References folder use relative binary references.

This offers several advantages. First, all a developer needs to do to
compile the product is get the lastest version of the MyProduct folder,
double-click the sln to open VS, and then build. If setup correctly it
should build everytime without having to track down missing
dependecies, syntax errors, etc. Second, versioning is very simple.
Since the product is completely self-contained you can label, branch,
tag, or merge at anytime. Each branch can use different versions of
the assemblies in the References folder. That's useful when you
receive a new version of a third party assembly and want to test its
compatibility with your product. If it's incompatible then you can
modify code accordingly in that branch.

Brian
 
M

MarkusR

Thanks Brian.

Brian said:
Markus,

I usually set it up like the following.

MyProduct\MyProduct.sln

MyProduct\Project1\Project1.csproj
MyProduct\Project1\File1.cs
MyProduct\Project1\File2.cs
MyProduct\Project1\FileN.cs

MyProduct\Project2\Project1.csproj
MyProduct\Project2\File1.cs
MyProduct\Project2\File2.cs
MyProduct\Project2\FileN.cs

MyProduct\ProjectN\ProjectN.csproj
MyProduct\ProjectN\File1.cs
MyProduct\ProjectN\File2.cs
MyProduct\ProjectN\FileN.cs

MyProduct\References\ThirdPartyAssembly1.dll
MyProduct\References\ThirdPartyAssembly2.dll
MyProduct\References\ThirdPartyAssemblyN.dll
MyProduct\References\SeperatelyVersionedAssembly1.dll
MyProduct\References\SeperatelyVersionedAssembly2.dll
MyProduct\References\SeperatelyVersionedAssemblyN.dll

Your product, whether shrink wrapped or in-house, should be completely
self-contained underneath one folder. There is a References folder
which contains all dependent third party assemblies and separately
versioned in-house assemblies. Projects that depend on each other use
a project reference while projects that depend on assemblies in the
References folder use relative binary references.

This offers several advantages. First, all a developer needs to do to
compile the product is get the lastest version of the MyProduct folder,
double-click the sln to open VS, and then build. If setup correctly it
should build everytime without having to track down missing
dependecies, syntax errors, etc. Second, versioning is very simple.
Since the product is completely self-contained you can label, branch,
tag, or merge at anytime. Each branch can use different versions of
the assemblies in the References folder. That's useful when you
receive a new version of a third party assembly and want to test its
compatibility with your product. If it's incompatible then you can
modify code accordingly in that branch.

Brian
 
J

Joerg Jooss

Thus wrote Robbe Morris [C# MVP],
Team Foundation Server is actually pretty nice. Pain in the neck to
install though.

http://www.eggheadcafe.com/articles/team_foundation_server.asp

I am forced to use Subversion at work. There is not
a day that goes by that I don't curse our former
CIO for forcing us to switch to Subversion.
That worthless Ankh for visual studio blows even worse.

God, I hate Subversion...

Praising TFS and cursing Subversion seems nonsensical to me, as both are
conceptually quite similar.

Cheers,
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top