Any plan on changing SLN format for TFS/SS mapping section to be merge friendly ?

Question

Any plan on changing SLN format for TFS/SS mapping section to be merge friendly ?

The automatic conflict resolution do most of the job automaticly.
But it often fail in SLN if two user added/removed projects at the same time.

If the mapping was using GUID as key (like other parts) instead of 4 properties indexed by the project index, the merge would be less painful.

Answer 1

Hello,

I absolutely understand problems related to the way we are storing Scc attributes in the solution file. Unfortunately we didn't get to changing it in this release. Don't worry - we remember about it and we want to greatly simplify them in the future (workspace mapping make most of those attribute redundant anyway).

---

Michal Malecki

Answer 2

Agree this is a huge problem.  It's not just the Scc attributes.  The mere fact that projects within the file are numbered in order means that the slightest change will cause a huge ripple effect (depending on how low its # is).  Predictability is also an issue; as soon as you add/remove something, you never know when VS will decide to re-number other unrelated projects just for fun.  Finally, the lack of a standardized, user-verifiable structure means that editing by hand is fraught with error.

Frederic, here are some existing Connect bugs:

https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=484784

https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=223625

https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=106331 

Please add your vote.  MS does take them into account.