Home/ Questions/Q 7863085
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-02T23:22:05+00:00

One of the reasons for using TFS shelvesets is for code review which I

  • 0

One of the reasons for using TFS shelvesets is for code review which I don’t agree, but this is the practice followed in my current project. The reason I see using TFS shelvesets is not a good idea for code review are

  • Shelvesets do not have a natural ordering as change-sets have. This
    can lead to lots of merge conflicts.
  • If developer cannot checkin code until it gets reviewed, it puts a dependency on the reviewer, and if the reviewer does not do review within a short duration these shelvesets
    can interfere with other tasks.
  • Collaboration with other devs becomes pain as now you need to pass shelvesets around rather than checkin code which can again cause merge conflicts in future.

Can someone provide me some pointers which can be either for or against the TFS shelveset approach for reviews so either I get convinced about the approach or I can present a case for not using this approach?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I think Microsoft disagrees with you a lot on this one, as the new Code Review feature in TFS 11 and Visual Studio 11 is built around shelvesets. The real issue is probably more around how the team operates and how tasks are split up across the product.

    If the tasks have been split such that they have few dependencies and such that the people working in the same area work closely together, then you won’t have any issues around merges and checkins. Should you have tasks taking more time, then regularly take the latest version from the development branch so that you’re always current.

    If you see that the Reviewer is too slow and that shelvesets are queueing up, all waiting to be reviewed, then this is where the other real problems can occur. When a task is finished it should be reviewed as soon as possible and not lie around waiting to be reviewed. If reviews take longer than 24h, then this can become a real issue. You could alleviate this by doing a peer review by someone else or by getting more reviewers on the team.

    If all else fails, you can do post-mortem reviews (review the changesets instead of the shelves), TFS 11 and Visual Studio 11 support this scenario as well.

    My personal preference is to trust the devs on my teams and we thus mostly do post-checkin reviews. If we have new or very junior members, then I’ll make sure that a more senior developer is available to do a first pre-checkin review instead.

    See also:

    • 0