Mapping issue on Visual SourceSafe

[Curious]

Hi,

I have the same .NET program developed on two machines, therefore, two
different versions, call them A and B.

There are following differences between A and B:

1) They have differences in source code;
2) Since A is developed in Visual Studio 2005 with .NET 2.0, but B is
developed in Visual Studio 2003 with .NET 1.1, the project files are
different.

I've been checking in the code from A to Visual SourceSafe from the
machine where A is developed. Now I want to check in the code from B
to the project location in VSS. But it has failed.

Here's what happened: When I tried to map B to Visual SourceSafe, it
seemed to require me to map both the hard-drive folder and the project
file (.sln) to VSS. While the folder location seemed to be mapped
successfully, the .sln file failed to match. It's "invalid".

Any advice on how to map B to an existing project location in VSS?

 

[Anthony Jones]

Hi,

I have the same .NET program developed on two machines, therefore, two
different versions, call them A and B.

There are following differences between A and B:

1) They have differences in source code;
2) Since A is developed in Visual Studio 2005 with .NET 2.0, but B is
developed in Visual Studio 2003 with .NET 1.1, the project files are
different.

I've been checking in the code from A to Visual SourceSafe from the
machine where A is developed. Now I want to check in the code from B
to the project location in VSS. But it has failed.

Here's what happened: When I tried to map B to Visual SourceSafe, it
seemed to require me to map both the hard-drive folder and the project
file (.sln) to VSS. While the folder location seemed to be mapped
successfully, the .sln file failed to match. It's "invalid".

Any advice on how to map B to an existing project location in VSS?

Source control management inside Visual studio is maddening at times and is
worse in VS 2003.
VS 2003 uses a project file to track content in a web, whereas VS 2005
simply uses the folder contents.

My advice would be a) Use 2005 and ditch 2003 (unless you still need to
support 1.1 for some reason) and b) when initialising a new source safe with
existing source use Visual SourceSafe directly not Visual Studio.

This approach allows you configure the layout of project and solutions in a
way you find acceptable rather than putting up with studio's choices.

 

[Jon Skeet [C# MVP]]

My advice would be a) Use 2005 and ditch 2003 (unless you still need to
support 1.1 for some reason) and b) when initialising a new source safe with
existing source use Visual SourceSafe directly not Visual Studio.

I'd go a couple of steps further:

a) Use 2008 and ditch both 2003 and 2005 if you can (you can still
write code targeting 2.0 in 2008)

b) Ditch VSS entirely and use a better SCM such as Subversion

 

[Anthony Jones]

I'd go a couple of steps further:

a) Use 2008 and ditch both 2003 and 2005 if you can (you can still
write code targeting 2.0 in 2008)

Of course most people will need to actually need to go out and buy 2008
unless they're happy with the Express version.

b) Ditch VSS entirely and use a better SCM such as Subversion

VSS isn't great but I find it does the job well enough on a well connected
network. Apart from a better infrastructure for more geographically
distribute developers what else does Subversion do better than VSS?

 

[Brian Gideon]

VSS isn't great but I find it does the job well enough on a well connected
network.  Apart from a better infrastructure for more geographically
distribute developers what else doesSubversiondo better than VSS?

Just about everything. In fact, I can't think of a function in VSS
that subversion doesn't do better. The big ones for me are branching/
merging and transactional commits.

I justed installed AnkhSVN (a 2.0 version built against subversion
1.5). It is a pretty good VS plugin now.

 

[Jon Skeet [C# MVP]]

Of course most people will need to actually need to go out and buy 2008
unless they're happy with the Express version.

Unless they use MSDN for their VS licences (which has been the case in
every place I've worked, actually). Even if they have to buy new
licences, I'd expect that the improvements in VS 2008 (mainly the
ability to use the new features of C# 3) will increase productivity
enough to pay for the licences pretty quickly.

VSS isn't great but I find it does the job well enough on a well connected
network. Apart from a better infrastructure for more geographically
distribute developers what else does Subversion do better than VSS?

Well for one thing, it actually keeps your source *safe*, without
corrupting it. No need to run repairs every so often which may or may
not fix issues. Simple incremental backup... but mostly:

o Very cheap branching
o Truly transactional commit support
o Good support for renaming (important for refactoring)
o Much better merging
o Portable (run the server on a Linux box, even if all clients are
Windows boxes) for example..
o Free
o Under visibly active development

I could go on, but it really is the first few which are important - as
well as the fact that it delivers on not losing your source code.

I can't emphasise strongly enough how much I prefer SVN to VSS. It's
like night and day...

 

[Curious]

It sounds like SubVersion is great. I found a website,
http://www.wandisco.com/subversion/, that contains free downloads.

But I see there are four options for me to choose:

MultiSite
High Availability
Clustering, and
Access Control

Which option shall I pick?

Also since my project (in VS 2005, .NET 2.0) is already in VSS. Will
using SubVersion mess up my project?

Will SubVersion cause all of my files "read-only" like VSS?

 

[Brian Gideon]

It sounds like SubVersion is great. I found a website,http://www.wandisco..com/subversion/, that contains free downloads.

But I see there are four options for me to choose:

MultiSite
High Availability
Clustering, and
Access Control

Which option shall I pick?

I've never seen those distributions. Personally, I would use
TortoiseSVN.

http://tortoisesvn.tigris.org/

AnkhSVN is a good VS plugin (at least a 2.0 build which isn't even in
beta yet).

http://ankhsvn.open.collab.net/

I actually use both of those clients right now.

Also since my project (in VS 2005, .NET 2.0) is already in VSS. Will
using SubVersion mess up my project?

Nope, in fact most subversion clients do not modify your projects
files at all (unlike VSS). So you never have any of those annoying
binding problems to worry about. It all just works perfectly with
SVN. AnkhSVN does have some binding information that it adds to the
project files, but I find even it works better than VSS.

Will SubVersion cause all of my files "read-only" like VSS?

Well, you can turn that feature off in VSS, but no, again most
subversion clients do not do this. I haven't noticed that AnkhSVN was
doing it to me either. You also need to understand that subversion
uses a completely different methodology for source control that makes
flagging a file read-only pretty much useless anyway.