Source Control in VS 2005.

[Frank Rizzo]

I am thoroughly confused by how VS2005 deals with source control
bindings. I've seen source control information stored in MSSCCPRJ.SCC
files, in solution files, in .csproj files.

I am not sure what makes VS2005 write SCC information to these various
places and in what circumstances. When we branch the code (we have a
lot of projects), it's a gigantic PITA to adjust the bindings.

Is there a guide somewhere that will tell me exactly how and in what
order VS2005 retrieves binding information.

Regards

 

[Cowboy \(Gregory A. Beamer\)]

Are you trying to work on the original code files, already on your machine,
as the branch files or are you creating a new branch folder? If the former,
it can cause issues, as you are changing bindings for a known point. It can
really mess you up if you accidentally get latest on the old branch. If the
later, it should be a simple matter of breaking source bindings and
reconnecting at the solution level.

If you branch on the back end (assume SourceSafe here?). Create your branch
and then download the bits from the branch. This allows you to have both the
old and the new. You can then remove all source bindings to the project and
rebind at the solutions level.

This works if you follow the MS way of setting up your solutions, projects,
etc. It can be a pain if you have tried to simplify the structure VS creates
in SourceSafe, however.

The one exception is web applications, which want to save the solution file
elsewhere. Not really a huge issue if everyone has their own solutions files
that are outside of source control. Otherwise, you have to control destiny
and place the files where you want them.

BTW, This is SO much easier with Team Foundation Server.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA
http://gregorybeamer.spaces.live.com
Co-author: Microsoft Expression Web Bible (upcoming)

************************************************
Think outside the box!
************************************************

 

[Jon Skeet [C# MVP]]

BTW, This is SO much easier with Team Foundation Server.

Well, it's a bit easier. I've personally been pretty disappointed with
TFS so far, compared with Subversion. There's still this crazy notion
that the server needs to know where you've fetched the source to. Why
can't I just fetch the source at any time to any path, and let the
*local* copy know where it came from on the server?

(That's far from my only complaint, but anyway...)

 

[Frank Rizzo]

Thanks for the response. I am using SourceGear Vault and we branch all
the time. Changing bindings is a pain because, not only do we branch
the code, but we also move it to a new repository (Vault allows multiple
repositories) for performance reasons.

So everytime we branch, I must track down where each project/solution is
keeping bindings (in the .sln or .csproj or MSSCCPRJ.SCC) and remove
them, then add a new. This is really time consuming.

You might ask why don't I just change the binding right in the IDE.
That's because, the vault plugin for vs2005 sucks - once it opens in a
certain repository, it is impossible to get it to change to a different one.

I guess I am looking to write a quickie app automatically changes
bindings when we branch. I just don't know where to start, since VS2005
seems to store the bindings all over the place.

Final question, is it a good practice to keep the MSSCCPRJ.SCC in the
repository?

Regards

 

[WenYuan Wang [MSFT]]

Hello Frank,

I think we need to perform more research on this issue, and will reply here
as soon as possible.
If you have any more concerns on it, please feel free to post here. We are
glad to assist you.

Thanks for your understanding!
Best regards,
Wen Yuan
Microsoft Online Community Support
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Frank Rizzo]

Hello Frank,

I think we need to perform more research on this issue, and will reply here
as soon as possible.
If you have any more concerns on it, please feel free to post here. We are
glad to assist you.

Thank you. Looking forward to hearing from you.

 

[WenYuan Wang [MSFT]]

Dear Frank.
Thanks for your wait.
I got some reply from VSS product team. Hope it helps.

During open_solution_from_disk, the IDE reads first the bindings in the
solution file.
Then IDE opens each project, and now scci has available the binding from
the project files.
The bindings in MSSCCPRJ.SCC are not stored by IDE - they are persisted by
the MSSCCI provider. The IDE reads those bindings if the bindings from the
project files are "SAK" (dummy bindings); when adding a project to scc the
IDE avoids writing real bindings in the project files if the MSSCCI
provider can create those mssccprj.scc files.
If there is a difference of bindings between solution / project's idea of
scc location, the bindings in solution are preferred.

Please feel free to update here,if you still have anything unclear. I'm
glad to assist you.
Have a great day.
Sincerely,
Wen Yuan
Microsoft Online Community Support
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Brian Gideon]

I am thoroughly confused by how VS2005 deals with source control
bindings. I've seen source control information stored in MSSCCPRJ.SCC
files, in solution files, in .csproj files.

I am not sure what makes VS2005 write SCC information to these various
places and in what circumstances. When we branch the code (we have a
lot of projects), it's a gigantic PITA to adjust the bindings.

Is there a guide somewhere that will tell me exactly how and in what
order VS2005 retrieves binding information.

Regards

I understand what you're saying. I've had to modify the sln and
csproj via notepad so many times. It is a frustrating and time
consuming process.

Now we use Subversion and things are much easier. Like Jon, I highly
recommend it. You can land working copies anywhere you like and never
worry about bindings. It is completely path agnostic in that
respect. Plus, it has atomic commit operations and the way you branch
and tag versions is much easier and a lot more versatile...just to
name a few ways that it's better

Brian

 

[PhilipDaniels]

Now we use Subversion and things are much easier. Like Jon, I highly
recommend it. You can land working copies anywhere you like and never
worry about bindings. It is completely path agnostic in that
respect. Plus, it has atomic commit operations and the way you branch
and tag versions is much easier and a lot more versatile...just to
name a few ways that it's better

Brian

Brian, can it cope with merging project and solution files - say two
developers both want to add a new file to a project...

 

[WenYuan Wang [MSFT]]

Hello Frank,

This is Wen Yuan again. I just want to check if you still have anything
unclear.
Please feel free to update here. We are glad to assist you.

Have a great day,
Sincerey,
Wen Yuan
Microsoft Online Community Support
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Frank Rizzo]

Hello Frank,

This is Wen Yuan again. I just want to check if you still have anything
unclear.
Please feel free to update here. We are glad to assist you.

Thank you. This is very good information.

 

[Brett Slaski]

The VS2005 plug-in from vault is really poor, yes. But it's not exactly
Sourcegear's fault as there isn't much flexibility in what you can do
with VS and source control.

I learned this early on using vault, and still use vault today (has been
at least 3 years now). The gui interface to vault is very easy to use
and allows you to put files anywhere you please. There are pro's and
cons both ways between Vault and SVN. I will basically say, if you
already paying for Vault, or have a large repository already, dump the
VS2005 pluging. Set your Vault client to work in a CVS mode and get a
new set of your files. The files don't need to be checked out of the
repository, no locking files or waiting for someone to come back from
vacation who has a file out. work on it app as you please and when you
are stable and want to write your changes, you get latest from the repo,
then merge in your changes.

Source control from within VS2005 is convenient, but it really does
suck. I have seen to many builds broke because of it.