6

When new files are added to a Visual C++ project, the IDE adds them in two locations:

  • The main project file (e.g. myproject.vcxproj)
  • The project "filters", a repository of the virtual paths of the solution explorer (e.g. myproject.vcxproj.filters)

Merging file additions is not a problem for the main project file, but it's very often a source of conflicts for the filters. The problem comes from the fact that the IDE always adds new elements at the very end of the filter list.

To illustrate the problem, let's say the filters initially look like this:

1 <ClInclude Include="fs\path\oldFile1.h">
2   <Filter>virtual\path</Filter>
3 </ClInclude>
4 <ClInclude Include="fs\path\oldFile2.h">
5   <Filter>virtual\path</Filter>
6 </ClInclude>

Then programmer A add newFileA.h and commits, the filters are updated as follows:

1 <ClInclude Include="fs\path\oldFile1.h">
2   <Filter>virtual\path</Filter>
3 </ClInclude>
4 <ClInclude Include="fs\path\oldFile2.h">
5   <Filter>virtual\path</Filter>
6 </ClInclude>
7 <ClInclude Include="fs\path\newFileA.h">
8   <Filter>virtual\path</Filter>
9 </ClInclude>

If programmer B also adds a newFileB.h and is note synced on the head revision, his local copy of the filters will look like this:

1 <ClInclude Include="fs\path\oldFile1.h">
2   <Filter>virtual\path</Filter>
3 </ClInclude>
4 <ClInclude Include="fs\path\oldFile2.h">
5   <Filter>virtual\path</Filter>
6 </ClInclude>
7 <ClInclude Include="fs\path\newFileB.h">
8   <Filter>virtual\path</Filter>
9 </ClInclude>

Trying to sync with the changes of programmer A will systematically provoke a merging conflict on lines 7-8-9 for programmer B. That's because the changes happen to occur at the exact same spot.

Is there a way to prevent this issue from happening, be it through a config change in Visual Studio, a special option of some merging tool (preferably Araxis Merge or Beyond Compare), or anything else?

Laurent Couvidou
  • 32,354
  • 3
  • 30
  • 46
  • What is ultimately trying to do the merge? If it is something like git then you can apply a merge strategy to handle this case. In short, it really depends on the tool that is doing the merge and how it applies them. Also, as MJD said, if this is for version control you can opt to simply not commit filters and let each user have their own. – Micah Zoltu Oct 20 '13 at 21:36
  • @micah-caldwell We're using Perforce for version control but we don't necessarily stick to P4Merge for merging. We use mostly Araxis Merge and Beyond Compare for that job. And for *not* commiting the filters, it might be a good idea, see my comment [below MJD's answer](http://stackoverflow.com/a/19474105/1005455). – Laurent Couvidou Oct 21 '13 at 19:54
  • Your answer will ultimately depend on the tool that does the merge. In the case of git, there is a merge strategy that can be useful in situations like this where it will add both when two additions occur in the same place. It is possible that P4Merge, Beyond Compare and/or Araxis Merge have a similar option. I recommend re-asking your question specifically for one tool (or multiple questions, one for each tool) as the answer will be tool specific. – Micah Zoltu Oct 22 '13 at 00:14
  • I'd prefer a solution involving Araxis Merge or Beyond Compare, but I'm open to any suggestion. If using git merge with Perforce is doable and would help working around that problem, well, why not. I've edited my question accordingly. – Laurent Couvidou Oct 22 '13 at 07:58

1 Answers1

1

Base upon this question, it sounds like filters are not necessary for Visual Studio to function. Have you tried simply not committing in your filter files, and instead having everyone have their own file? I don't use VS, so I don't know what those files do, or what functionality wouldn't be synchronized. However, I generally don't recommend committing in IDE specific files, as they generally change for different users, and are just a source of conflicts anyways.

Community
  • 1
  • 1
MJD
  • 1,183
  • 7
  • 13
  • Not committing the filters isn't really a solution for us. Doing so would render the whole project hierarchy flat, and as this is a pretty big project the result wouldn't be really practical for everybody. Buuut... maybe we shouldn't use the filters at all, I've seen somewhere that VS was capable of using the folder structure directly... – Laurent Couvidou Oct 21 '13 at 19:22
  • It's possible to use the folder structure directly [through the Show All Files option of the solution explorer](http://stackoverflow.com/a/15678083/1005455). But as this is not the default for Visual so I fear that this might not work for everything. Still, this might be the only real solution to this problem (apart living with it), so +1 for you. – Laurent Couvidou Oct 21 '13 at 20:09
  • Oh and to be clear: what those "filters" do is that they hold a virtual folder structure that is completely disconnected from the actual file system. This is why not using them would flatten the project hierarchy, at least when using the default mode of the solution explorer. – Laurent Couvidou Oct 21 '13 at 20:15
  • Ah, I understand. I don't use VS, so I don't have any other solutions really. Sorry I couldn't help further. – MJD Oct 21 '13 at 21:59