VSS with VS.NET

[Mark]

We're installing VSS to use with VS.NET for our team. How does this work --
will people check out the entire project, or only one file at a time? If
they only check out, for example, a single page and it's code-behind, how
are they able to test it? If they check out the entire project, then no one
else could make changes to the project ...

Comments? Thanks in advance! - Mark

 

[William Ryan]

YOu can check out the whole project, solution, or just individual
components. You can even put stored procs and Excel/Word docs under it.

If the solution is checked out, but not all of the components, let's say you
check out the Solution and Form1, but not form2. I can still check out
form2. However, I can't add anything to the solution if it's checked out.

The admin can overide checkouts in case of emergency.

It's pretty straightforward and a live saver in general.

 

[Mark]

Great, so in your example, would you be able to run and debug form2? Or
would I be the only one able to do that? Assume we're using File Share
rather than frontpage server extensions.

Thanks again! Mark

 

[Chris Capel]

The way source control works is that anyone can have every file, even if
it's not checked out. To have a file checked out means to be able to modify
the local copy of the file.When a file isn't checked out, the local copy can
still remain, read-only. VS doesn't have any problem debugging using
read-only files.

You can also set up VSS to allow multiple check-outs, if you wish. Then
multiple people can edit the file at the same time, and when the changes are
checked in, they are merged. If the merge can't be done automatically, you
can do it manually with the built-in merge tool.

All this is totally integrated into VS. This integration is what makes VSS
such a nice tool for VS users. Otherwise, something like CVS (unix de facto
source control standard) would probably be preferred.

Chris

 

[Mark]

Cool. So when we each check out the solution, or a read only copy, we'll
then be working locally on our own local IIS install? Or are you still
leveraging the central web server that has the live files?

WAIT - maybe I haven't thought this through. What suddenly makes more sense
is that the VSS will be on an entirely separate file server running some
flavor of Windows. We'll check it out, and each run it locally on our own
IIS 5.0. THEN, when we want to go live with something, we'll just copy the
necessary .aspx and .dll files over to the live web server.

Correct? Thanks again! Very useful.

Mark

 

[Chris Capel]

You have it straight. In general, I'd avoid editing things on a remote
server, unless you make it clear what *you're* working on and that no one
else should work with that part of the project at the same time. Otherwise
development's pretty much impossible. By far, the best solution is to have
each developer run his/her own copy of IIS, and then use VSS to keep all the
changes synched. And you're right, VSS can't really be used effectively when
you're running and developing off of a remote server. If you don't want to
use a source control at all, having everyone developing off the server would
probably be more feasible. But I've never done that, so I'm not sure!

Chris

 

[Mark]

very helpful. Thank you! - Mark

You have it straight. In general, I'd avoid editing things on a remote
server, unless you make it clear what *you're* working on and that no one
else should work with that part of the project at the same time. Otherwise
development's pretty much impossible. By far, the best solution is to have
each developer run his/her own copy of IIS, and then use VSS to keep all the
changes synched. And you're right, VSS can't really be used effectively when
you're running and developing off of a remote server. If you don't want to
use a source control at all, having everyone developing off the server would
probably be more feasible. But I've never done that, so I'm not sure!

Chris