0

We currently have 5 developers working on quite large Silverlight application. We have 3 servers:

  • Test
  • User acceptance server
  • Production

Each person works on something completely different and rarely do they run into each other's code. When they do, they just merge it while checking in their changes.

The biggest problem we have currently is following scenario:

  1. One person works on some module and it's finished but we don't want it to be released yet.
  2. Second person works on some bug fixes etc. those need to be released.

Both people checked in their code. Now how do we select/pick changes we would like to keep in a specific build.

Is there a way of creating custom build based on specific check-ins? Can we revert some changes?

I have previous experience in git/hg and I only just started using TFS for this project. What I used to do in Git was to create a new branch per feature and each person would work on their branch. If a person was working on general bug, they would then check it in to the master branch and other people would just pull it to make sure they are up to date. When the feature was finished we would then merge the branch into the master branch. TFS seems to be very fragile and every time I tried doing something with it I either ended up losing some changes I made or ending up with many hours trying to fix some random issues I created by doing simple tasks such as check it or get latest.

Are there any tutorials (more hands on) available?

Improve this question
1
  • TFS Version Control is quite resilient provided that you use it as intended. It is a centralized version control system, whereas git is a decentralized version control system. It sounds like what you need is a branching strategy. You could potentially use continuous integration to perform builds for each branch (perhaps one feature-based branch for each dev) at check-in.
    – ravibhagw
    Commented Apr 4, 2014 at 2:27

2 Answers 2

Reset to default
3

I favor a branch-per-feature situation and merging back into a stable main for this situation - it may be helpful to read Microsoft's Branching Guide for Team Foundation Server, which refers to this as "segregated feature work".

Obviously a DVCS is going to have different characteristics when working with branches than a centralized version control system like Team Foundation Server, but the setup you're describing is very common (it mirrors the branching model used by the team developing Team Foundation Server, in fact) and shouldn't really be all that fragile.

I wonder if it's a difference in expectations between the way TFS merges and the way git merges. If you could describe what sorts of problems you're having in a bit more detail, I might be able to provide better resources.

Improve this answer
2

You could you use shelvesets in TFS to do something like that.

anyone who wants those changes could then check out the shelve set, etc

Improve this answer
1
  • I see so sort of like stash in git. Rather than checking it I shelve those changes for later? Not bad. I hope it is not the only solution though.
    – Luke
    Commented May 26, 2011 at 1:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.