.NET Questions (CLOSED)

Questions and Answers on any aspect of .NET. Now closed.

This discussion group is now closed.

Have a question about .NET development? Try stackoverflow.com, a worldwide community of great developers asking and answering questions 24 hours a day.

The archives of .NET Questions contain years of Q&A. Even older .NET Questions are still online, too.

Visual Studio and sourcecontrol (subversion)

Hi,

Have anyone found any really good way to use Visual Studio with sourcecontrol? We're using Subversion right now, but this is probably an issue with many source control providers.

Specifically, the project files (.csproj, .vbproj, the project files themselves, that is) are really messing things up. Things get complicated when 2 users both make changes to a project (such as adding a file). The project files themselves are now in conflict (since Visual Studio stores information about which files to compile and how as part of a project). They certainly can't be merged.

Have anyone found a solution to problems like this? A solution could of course be to use file locking when editing a file, I guess, but that limits a number of things in other areas.
Andreas Nilsson Send private email
Wednesday, January 11, 2006
 
 
When making the choice not to use locking - letting two users edit the same file at the same time - you need to realize this means that there will be situations where a manual merge of versions will be the only way.  The situation you just described is one of those situations.  Get the two developers who made the changes merge the  versions together and make sure everything works before checking in the new merged file(s).
Todd Schneider Send private email
Wednesday, January 11, 2006
 
 
In our dev shop we all use the same project files, i.e. the project files are under source control too.

We moved to this from our previous position of everyone having seperate project files a few months ago. I was sceptical at first but it seems to work ok.

Obviously you have to allow multiple checkouts/merge in this scenario. It' also important to have an automated build of the latest version on a a daily basis, to catch any problems early.
brine
Wednesday, January 11, 2006
 
 
We use subversion as well. 99% of the time, it merges the project files fine. The other times you have to edit the project file by hand, since it is XML it is pretty easy to figure out.
Lorad
Wednesday, January 11, 2006
 
 
We use VS 2005 and SVN with 2 developers. We have never had a problem with projects being modified or projects added/removed from the master solution. SVN always merged without conflicts.
Keith Send private email
Wednesday, January 11, 2006
 
 
We use VS 2003 / 05 with 6 devs.  We version control all the files - .csproj and .sln.

Never had a problem.
Sassy Send private email
Wednesday, January 11, 2006
 
 
Basically, the problem seems to lie with the standard diff program svn uses to merge files when updating the local repository. We're using Visual Studio 2005, by the way.

For example, if two developers each add a new file to a project (via Visual Studio, for example), these files will both have the newly added file on the same row in the .csproj file. After both developers have added their files, the .csproj files might for example look like this:

Project file for developer 1:
-----------------------------

...
<ItemGroup>
    <Compile Include="File1.cs" />
    <Compile Include="SubDir\OldFile.cs" />
    ...
</ItemGroup>
...

Project file for developer 2:
-----------------------------

...
<ItemGroup>
    <Compile Include="File2.cs" />
    <Compile Include="SubDir\OldFile.cs" />
    ...
</ItemGroup>
...

Now, File1.cs and File2.cs are on the same row in the project files that are to be merged, which the basic svn diff can't handle.

Is there any generic solution to this (other than possibly switching diff program)?
Andreas Nilsson Send private email
Wednesday, January 11, 2006
 
 
Would another diff program come up with different results? I would think that any algorithm that would recognize your example as a "merge" would then annoying recognize simple bug fixes like "oops I had a 1 instead of a 2" every time.
Matt B Send private email
Wednesday, January 11, 2006
 
 
Just be a little more careful about checking sln and proj files in and make sure that the developers checking them in are leaving detailed enough comments on their changes.
Matt B Send private email
Wednesday, January 11, 2006
 
 
It's probably easiest to take care of this by letting all your developers know that when they need to edit the build files, they must do so quickly, under 5 minutes.  That means if you add a new file to the project you have to check in an empty file that doesn't break the build before starting to add code to it, so that the project file can be checked in at the start of development and not the end.
Chris Send private email
Wednesday, January 18, 2006
 
 
Why on earth would you have two people working on the same project at the same time? If there are multiple subsystems, why aren't they coded, tested and released as separate assemblies?

We use svn with vs2005 too. Our assemblies - once released to the group for use - occasionally get bugfixes but otherwise are very stable. It is extremely unusual for public interfaces to change.

We achieve this not by some miracle of prescience in the planning stage but by building unit tests that are a complete microcosm of the intended use. These serve both to provide convenient regression testing when changes do happen and as comprehensive how-to sample code.

If anyone manages to ask a sensible how-to question that isn't covered, a gap has been exposed in the unit testing. The gap is addressed by the dev who looks after that unit because extending the test generally exposes weaknesses and unhandled edge conditions that the creator is best equipped to handle.

This approach sounds like a lot of work and it is. Which is good. It teaches us focus. Laziness makes us build assemblies that do exactly what they're supposed to do, no more and no less.

The stronger your architecture, the less trouble you will have, I think.

Besides, splitting things up like this gives everyone a chance to be the god of their own little world, always a hit with programmers.
Peter Wone Send private email
Wednesday, January 25, 2006
 
 

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

Other recent topics Other recent topics
 
Powered by FogBugz