The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

(ASP).NET and Source Control

All,

We're starting on an ASP.NET project and are wondering how most people deal with .NET projects and Source Control. For example, how do you deal with all the non-source files that make up a .NET project (e.g. the project and solution files)?

All of our .NET projects to date have been mostly single-developer ones so trying to deal with multiple developers adding files (and checking out the project/soln files) is something we've never encountered.

Ideas? Thoughts?

Also, any source control software to AVOID? We were going to use MS Source Safe but it's horribly ancient.

Thanks!
Dr. Mario Send private email
Thursday, February 03, 2005
 
 
If you're using VSS from VS.NET, all the project files etc are added automatically. There's a guide somewhere on MSDN about VSS and VS.NET - "Team development with Visual Studio .NET and Visual SourceSafe". This might help.
el
Thursday, February 03, 2005
 
 
VSS is old, but it's also, by far, the most used VCS (a million little teams out there rely on VCS). The probability of one of the oft repeated horror stories happening is significantly higher simply because of the usage.

This isn't to say that it's a great version control system - it has tonnes of weaknesses, and the file-database system is pretty archaic and limits usage with something like Source Offsite. However it should be satisfactory for small teams (particularly if you don't have to hit the solution file often), and the integration is Visual Studio.NET is top notch and trivial to use.
Dennis Forbes Send private email
Thursday, February 03, 2005
 
 
>... For example, how do you deal with all the non-source files that make up a .NET project (e.g. the project and solution files)?

Development involved multiple VS projects, multiple development groups, one's group assembly may be consumed by another group, etc. We put as requirement that code in SCC must be at least compilable and preferably all unit tests are ok at all times. As result we had to enforce use of project references in solution and organize work with project/solutions like this:

Project file is always in VSS; developers working on the project share responsibility for the file; check-out time should be reduced to minimum, which added new development requirement: when someone makes a new class, it is added to the project as a file with empty class stub or even just an empty file; developer compiles project/solution  and checks project in.

There is solution file (in SCC) with all projects for complete product build, which is maintained by one person. For the convenience of groups or individual developers it is ok to maintain their own solutions in SCC or locally and it becomes their responsibility to update solutions when new project should be added. They can always use master solution for up-to-date reference.


> Ideas? Thoughts?

> Also, any source control software to AVOID? We were going to use MS Source Safe but it's horribly ancient.

Features VSS lacks or has problem with compared to more modern couterparts:

- no atomic commit: you need to do extra work to identify modified files as part of one functional change and it is possible to get partially checked-in project from VSS.

- no unicode support: you have to use binary storage format and lose compare version ability.

- no external merge/diff tools allowed, bad network performance, problems with large databases etc. etc. ok, it IS ancient. :)

VSS and Integration with VS.NET problems

- DB project may allow to add files when another developer checked it out

- File rename/move is a nightmare. If you have codegenerated files it's doubly so.


Anyway if you have a chance - try to go with VS 2005 TF - with all novelty of the product (read "expect service packs soon") claimed SCC/TaskTracking functionality sounds extremely good.
DK
Thursday, February 03, 2005
 
 
I'd get the book "Pragmatic Source Control with CVS" whether or not you're using CVS.  It does a pretty good and quick job explaining the basics and concepts behind source control.  This is severly lacking in most of the documentation for various SCM products, in particular the Cederquist manual.

Thursday, February 03, 2005
 
 
someone asked recently how people set up vs projects. this is a similar questions, so i'll give a brief overview of one way to do it:

don't use asp.net projects. well, use them for test projects, but not for checked in ones.

use nant instead to build. and a class library project to hold all your code/aspx pages/etc. in the IDE.

then nant can generate your output (for the web server). a bit more of a hassle then working 'live' like vs wants to do, but much more repeatable in terms of multiple people using a system, or returning to something which hasn't been touched in months.

vs.net 2005 seems to be headed towards this model.
mb Send private email
Thursday, February 03, 2005
 
 
I use and recommend Subversion with AnkhSVN

http://subversion.tigris.org
http://ankhsvn.tigris.org

Subversion is a far better VCS than VSS.  And AnkhSVN provides the basic VS.NET integration without the SCC-API restrictions that I saw in Igloo (CVS/VS.NET integration) and VSS itself.
Andy O
Thursday, February 03, 2005
 
 
You might like to try Vault.  While you can integrate it with the IDE, it suffers from many of the same problems (renames etc) when used in that mode, due to the limitations of Visual Studio's support for source control tools.  (It doesn't suffer from SourceSafe's reliability problems tho!)

Instead, you can use it in "CVS mode", and just turn off the integration with the IDE.  I've only tried this breifly, but it seems to work well.  The idea is that all working files are writable, explicit checkouts are not required, and the Vault client application tracks the state of your working folders versus the repository.  So you can easily see which files you've changed and (atomically) check them in.
John Rusk Send private email
Friday, February 04, 2005
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz