If there is a conflict, one of their choices to resolve the conflict is
just "keep mine" and another is "take what is coming in". I wasn't
quite sure what you wanted to "undo". If a file is checked in, you can
undo it by just renaming the file, copying the renamed file to its
original location, and then deleting the renamed file.

Cheers,
Geoff

On 11/1/2010 7:38 AM, yaron wrote:

Hello,

I have a team that works with VS 2005 and RTC 2.0.0.2 IFIX3.
Currently several team members are changing the solution (sln), and
they have from time to time the merge scenario.
They do not want to perform merge since the sln files are not regular
files and contain info that can not be merged.

They would like to be able that everyone will change, but whenever a
change was delivered, other users will be able to take the changes
without merging with their own chnages.
Within this scenario currently other users also checked in the sln and
they can not perform the undo.
Is there a best practice for managing sln files?

Thanks,

Yaron Norani

Hi Yaron,

As Geoff suggested, one workaround is to accept all the incoming changes, this will show merge conflicts for the .sln file in your example. If you do not want the incoming changes to .sln files, you can resolve the merge conflict as "Resolve with mine". This will leave your version of .sln file in your repository workspace.
Although I don't very well understand if you really need to deliver changes to .sln file, if users want to work with different versions of .sln file. You might want to take a look, if it's not required to deliver the modified .sln file, then the merge conflicts for other users won't arise.

In the forthcoming 3.0 version of RTC for visual studio client, we plan to provide support to share projects without sharing .sln file. This might be helpful in your scenario here.

Hi Prabodh,

when are .sln files changed? In case a file gets renamed or when adding items/files to the solution?

What about locking, would id be advisable to lock the .sln file in case manual changes are done?

Ralph

Hi Yaron,

As Geoff suggested, one workaround is to accept all the incoming changes, this will show merge conflicts for the .sln file in your example. If you do not want the incoming changes to .sln files, you can resolve the merge conflict as "Resolve with mine". This will leave your version of .sln file in your repository workspace.
Although I don't very well understand if you really need to deliver changes to .sln file, if users want to work with different versions of .sln file. You might want to take a look, if it's not required to deliver the modified .sln file, then the merge conflicts for other users won't arise.

In the forthcoming 3.0 version of RTC for visual studio client, we plan to provide support to share projects without sharing .sln file. This might be helpful in your scenario here.

Hi Prabodh,

when are .sln files changed? In case a file gets renamed or when adding items/files to the solution?

What about locking, would id be advisable to lock the .sln file in case manual changes are done?

Ralph

Hi Ralph,
In the scenario that Yaron mentioned, there are several users who have a different local copy of .sln file. And looks like the changes to .sln file are fairly frequent for them. Locking will be useful if we want to enforce changes by only one user at a time, in the sense that I start making my changes only if I can get a lock on .sln file, otherwise I wait (else I'll still get merge conflicts). Moreover the change to .sln file will most likely be a part of some bigger change, so one always needs to be careful which change might update .sln file, and acquire a lock only then.
It is for the users to take a call if this solution works for them, but in my opinion it might not please them much.