5 ms·

I'm now suffering a lot of rebase pain while working on a new .Net project. I'll give it a go. I'd be great if there was a strategy for fixing conflicts with V

by lukasm 12y ago

I'm now suffering a lot of rebase pain while working on a new .Net project. I'll give it a go. I'd be great if there was a strategy for fixing conflicts with VS files.

eterm 12y ago
The inability of VS to play nicely with merging is a real pain. (DBML files in particular are a huge headache, but .csproj, .sln, .config files also are troublematic). I'm not sure I follow the author's issue with control merges though. Apart from a dogmatic statement that merges should be final (says who), what problems do control merges create?
- stinos 12y ago
  What problems did you have exactly with sln/project/config files? They are plain text after all so if there are conflicts they should be of the same 'level' as conflicts in code files (i.e. can be a breeze to merge or a f*ing pain depending on the situation).
  - DougWebb 12y ago
    The problems are twofold. First, these files and some others that VS uses are XML, and XML has this property where semantically-equivalent files can be structurally-different. Empty elements can be rendered with or without end tags, empty attributes can be present or absent, whitespace between tags doesn't matter, etc. (sln files aren't really XML, but they're XML-like in their structure. I've had fewer problems with them than the other files.) The second issue is the way Visual Studio modifies these files: it reads and parses them into a DOM tree, makes changes to the DOM, and then serializes the DOM back out to the file. So a small change in one part of the project causes the entire file to be re-written, and it often gets restructured in the process. I've found this to be a bigger problem when different developers are using different versions of Visual Studio; at my company we've had 2010, 2012, and 2013 all in use at the same time on the same projects until everyone upgraded. (And we had good reasons for not upgrading everyone at once.) I guess there's a third reason: most .NET developers never look at these files directly; for the most part they are only modified through Visual Studio. So, although they're just text files and conflicts are resolved the same way they're resolved in code, that's made more difficult by not knowing what the files are supposed to look like or what the correct resolution should be. The sln files are particularly annoying in this regard because they're about 80% Guid strings and 20% readable text, so it can be really hard to understand the diff. When I started working with .NET, I had to learn all about these file formats when I started running into conflicts in them, and now I'm comfortable fixing conflicts and often editing them directly. I've helped most of my team gain the same comfort level, so we don't have problems anymore. The conflicts, when they happen, are just annoying now.
- ljoshua 12y ago
  I'll second this. Half of my conflicts when working on .NET projects are related to changes in .csproj, DBML, or EDMX files. I understand the function these files perform, but it certainly doesn't make it any easier. Just because I and a colleague happened to both add completely independent files to a project doesn't mean I should have to deal with a conflict.
lmm 12y ago
I tend to find it best to .gitignore any IDE files. IDE project import can (or should be able to) regenerate them as and when necessary.

by lukasm 12y ago

I'm now suffering a lot of rebase pain while working on a new .Net project. I'll give it a go. I'd be great if there was a strategy for fixing conflicts with VS files.

eterm 12y ago

The inability of VS to play nicely with merging is a real pain. (DBML files in particular are a huge headache, but .csproj, .sln, .config files also are troublematic). I'm not sure I follow the author's issue with control merges though. Apart from a dogmatic statement that merges should be final (says who), what problems do control merges create?

stinos 12y ago
What problems did you have exactly with sln/project/config files? They are plain text after all so if there are conflicts they should be of the same 'level' as conflicts in code files (i.e. can be a breeze to merge or a f*ing pain depending on the situation).
- DougWebb 12y ago
  The problems are twofold. First, these files and some others that VS uses are XML, and XML has this property where semantically-equivalent files can be structurally-different. Empty elements can be rendered with or without end tags, empty attributes can be present or absent, whitespace between tags doesn't matter, etc. (sln files aren't really XML, but they're XML-like in their structure. I've had fewer problems with them than the other files.) The second issue is the way Visual Studio modifies these files: it reads and parses them into a DOM tree, makes changes to the DOM, and then serializes the DOM back out to the file. So a small change in one part of the project causes the entire file to be re-written, and it often gets restructured in the process. I've found this to be a bigger problem when different developers are using different versions of Visual Studio; at my company we've had 2010, 2012, and 2013 all in use at the same time on the same projects until everyone upgraded. (And we had good reasons for not upgrading everyone at once.) I guess there's a third reason: most .NET developers never look at these files directly; for the most part they are only modified through Visual Studio. So, although they're just text files and conflicts are resolved the same way they're resolved in code, that's made more difficult by not knowing what the files are supposed to look like or what the correct resolution should be. The sln files are particularly annoying in this regard because they're about 80% Guid strings and 20% readable text, so it can be really hard to understand the diff. When I started working with .NET, I had to learn all about these file formats when I started running into conflicts in them, and now I'm comfortable fixing conflicts and often editing them directly. I've helped most of my team gain the same comfort level, so we don't have problems anymore. The conflicts, when they happen, are just annoying now.
ljoshua 12y ago
I'll second this. Half of my conflicts when working on .NET projects are related to changes in .csproj, DBML, or EDMX files. I understand the function these files perform, but it certainly doesn't make it any easier. Just because I and a colleague happened to both add completely independent files to a project doesn't mean I should have to deal with a conflict.

lmm 12y ago

I tend to find it best to .gitignore any IDE files. IDE project import can (or should be able to) regenerate them as and when necessary.