No SourceSafe-style Sharing in VSTS - what do I do instead?

  • [アーティクル]

Last post, I wrote about the lack of sharing. The question I didn’t answer was, “Well, what should we do instead?” This question came up on the forums in this post, and evolved into a specific scenario; here’s an excerpt:

 

We are developing applications that will work on Windows machines, Windows Mobile machines as well as the web. We create a solution for each platform … We then have shared class files that contain common business logic … What is the best method for supporting this type of scenario in TFS?

 

Here’s my brief answer on a suggested approach to the problem:

           

1. Create one folder or tree that a given shared class file or library is maintained within.

2. Branch this folder or tree to a location within each solution tree that needs the shared logic.

3. Lock(:checkout) or deny PendChange permission to the solution 'child' branches, so that changes can only be made in the 'master' shared location.

4. When changes are made, merge from the master to the child branches. Since these branches aren't changing separately, merging to them will be straightforward (only a handful of operations like renames and undeletes will still conflict).

 

Do you think this is a viable alternative to sharing? The need to merge the changes as a separate action from changing the shared code is a tradeoff – it’s not automatic, but you can also tweak the branches if platform specific adjustments do turn out to be necessary, without losing the shared history and the ability to merge in additional future changes.

 

Update: Almost forgot - For additional technical details on branching and merging, and some of the details of why we prefer this approach to sharing, see Buck's blog post on the topic.

 

Update2: Buck just pointed out to me that Step 3 isn't quite right - what I really meant was that you'd want to limit modifications to the shared code to owner or maintainer of it, and they'd probably want to always change the 'source' and merge it to the various targets, whereas with shared code it doesn't matter which instance is modified (part of the danger, from my perspective).

 

If I were the maintainer, I'd probably have a separate workspace where I worked on the shared code, and keep the shared code locked in that workspace. That way, I wouldn't be able inadvertently/haphazardly modify the shared code myself, as part of other work -- in my 'regular' workspace, I'd get the same lock error anyone else would.

 

Off to neverneverland...
Chris

Comments

  • Anonymous
    August 11, 2005
    Based on what I've seen in the MSDN forums, people are having different problems migrating their code...
  • Anonymous
    July 07, 2006
    General
    If you only had time to read only one VSTS site, I suggest Rob Caron's: http://blogs.msdn.com/robcaron/...