9

It’s become an annoying factor of working with large teams: how do you manage checkins and prevent feature conflicts and manage dependencies with source control properly?

Currently at my workplace we use TFS 2008 and we're migrating to TFS 2010 in early December. Firstly any source control is better than none but what approach has anyone found useful to prevent multiple checkins and rollback all over source control history? Is a volatile trunk the best way to go or branch off when your implementing a new feature and once you're happy merge back into the trunk?

I'd really like to hear other people experiences and perhaps some best practices to managing source control.

Improve this question
5
  • 2
    Possible duplicate of programmers.stackexchange.com/questions/5540/…, programmers.stackexchange.com/questions/15730/…
    – Adam Lear ♦
    Commented Oct 12, 2011 at 3:31
  • 3
    The best solution I found to deal with TFS was to have my own private GIT where I can shuffled around with all the branching I need and perform commits on TFS per minor milestones (small feature, partial feature) the smaller the better but you must also make sure the code is sound when you commit. On the one branch per feature / bugfix / iteration I would commit to TFS at the end of the "branch". However internally it is quite common for me to have multiple branches for the different trials and explorations. TFS Power tools here is quite useful to automate the merge back
    – Newtopian
    Commented Oct 12, 2011 at 4:28
  • 1
    Please elaborate more on what you mean by "multiple checkins" and "violate trunk". I truly hope that each of my engineers is doing more than one checkin while members of my team.
    – Manfred
    Commented Oct 12, 2011 at 5:58
  • source control branching strategy is a large topic. programmers.stackexchange.com/questions/107884/…
    – gnat
    Commented Oct 12, 2011 at 7:17
  • @John - I think "violate" was a typo for "volatile"
    – ChrisF ♦
    Commented Oct 12, 2011 at 11:44

8 Answers 8

Reset to default
7

TFS? Run for the hills! Move off as quickly as you can. It does a lot of different things but none of them as good as the available best of breed tools.

But seriously:

Once you have a decent version control system (SVN, GIT, etc.) I'd recommend setting up rules for branch management, e.g. when to create branches, for what, when to merge, who, and a lot more.

Until recently we used a single branch for new development ('trunk'). For a release we would create a branch off trunk. Final QA would be done in that branch and once completed we would release (we are on monthly releases).

We have switched to the concept of 'no junk in the trunk' to reduce the schedule risk. This concept basically contains a rule by which you'd create branches for development work separate from trunk. For example you could have a separate branch for a feature, for a small development team or similar. We use 'epics' to describe a small feature or releasable part of a feature and create a branch for each epic. At least once a day all changes from trunk are merged into the epic branch. Key is good merge support by version control or a separate tool (e.g. three way merge). QA for the epic would be done on the epic branch. Once passed the epic branch would be merged into trunk and an integration test be run. We still have branches for releases.

With the epic branches we have substantially reduced the schedule risk as we are now in a position to release out of trunk and include all epics that were successfully merged into trunk. Epics that are not complete miss the bus and will make the next release (next month).

This of course may work only in our environment. Very likely you will have factors different from ours that will influence what the best choices are for branch management.

For example if you have a team with a lot of people working remotely and not always being connected to the version control server, then you would want to use a version control system that supports a distributed model. GIT and a few others would fall into this category. TFS to the best of my knowledge requires a connection to the server to just make files writable (fixed in version 2010?).

I hope I was able to show that there is not "one size fits all". Start with your processes in particular branch management, determine the requirements and finally select the tool that is the best match for your needs. Maybe it is TFS, maybe not.

Improve this answer
4
  • 2
    "TFS? Run for the hills!" - I'm tempted to create a second account so that I upvote this twice.
    – Ant
    Commented Oct 12, 2011 at 12:31
  • Good to hear that this works for you. I've been in similar projects where this was required. But the way you make the merge of "epic" branches makes it sound easy. I would like to put in that it more than likely be a horrible pain each time.
    – Lionel
    Commented Oct 12, 2011 at 23:00
  • 1
    @Lionel: I agree, this can happen. I have seen something similar in the past going horribly wrong, too. In my experience key to successfully using this approach is to keep the delta between trunk and feature branches as small as possible. At least once a day you need to merge from trunk. Equally it pays off to have the epics/features as small as is viable, e.g. more on the days/weeks scale than many months. Extremely beneficial is also a clean architecture and design and a (fully) refactored code based.
    – Manfred
    Commented Oct 13, 2011 at 1:54
  • @John Completely agree with your last comment. The main problem I have experienced in the past is that "new features" are usually big, complicated, and contains design changes to existing code in the trunk. These may take months to implement and test. Merging these into the trunk would be a nightmare when there are more than one team working on different features.
    – Lionel
    Commented Oct 13, 2011 at 2:55
4

I advocate one branch per feature as it allows great flexibility when deciding which features to ship & which to defer.

How well that works in your situation is dependent on how well your VCS handles branches and more importantly merging. DVCS like Git & Mercurial make this a relatively trivial exercise. SVN less so. I've managed to avoid TFS though I have read a lot about it, mostly uncomplimentary I'm afraid. If you're stuck with TFS do a small pilot release based on one feature per branch & see how well the merging goes for you.

Improve this answer
2

Firstly, a disclaimer. It is difficult to say what is the best way of managing your source, since we are not aware of how your team or teams work on a day to day basis.

Generally, it is better to work on the trunk. For each major release, branch it - so that bug fixes for the release version are on the branch which can be merged back into the trunk. All developers work on the trunk and commit code regularly (minimum once a day).

Merging new code in regularly minimises the pain of merging in large chunks of code in a massive integration phase. By spreading out the pain, you'll feel it less. The more often your team members commit the code, the less they'll have to merge - because they'll always be on the latest source.

Improve this answer
2
  • 2
    I totally disagree on working on the trunk. If the trunk get broken everybody will be affected. I also disagree on branching after a major release, what if a bug affects two or more releases, you fix it in every branch ?
    – Trasplazio Garzuglio
    Commented Oct 12, 2011 at 8:38
  • @marco-dinacci: What you're saying may be correct if you have more than one release being maintained at anyone time. However, you're ignoring the fact that the fixes for those bugs would be merged back into the trunk. The other releases could then pull the changes. Regarding the breaking of the trunk. Before you commit code into the trunk, you're supposed to ensure that you have all the latest source and that your change didn't break the trunk. If it is broken, you should not commit until it's fixed. Of course, there are of course pros and cons to the different approaches.
    – Lionel
    Commented Oct 12, 2011 at 11:18
1

I've never used TFS 2008/2010 but from what I have read in various forums there are much negativity about using TFS for version control. This has made me stay clear from TFS from so far.

I'm currently using SVN and Git, I find them both good for small teams or single man team but wouldn't personally recommend SVN for a large team.

I've had my eyes on PlasticSCM for and will try to that in the near future.

I apologize for not answering your specific question, would have posted a comment if my privileges allowed me to.

Improve this answer
1

I think git makes all other source control software obsolete. Branching and merging are easy, and if there are problems, it gets contained, but a lot of problems get avoided by how it encourages very frequent commits, branching, and merging. Each user gets a full copy of the repo (this can be pruned, but I work with a pretty huge code-base and it is not a problem), so there's something of an automatic backup. Commits/push/pull are quick, and one of the most important things is that it breaks the coupling between file name and tracking. The file data, including the name and path, is a data blob that is referenced by a tree node, that is independent of paths. This is not only safer, but certain kinds of "don't ever do that" issues in something like SVN are not a problem. It can be used as a traditional hub configuration or peer to peer, and those uses can be mixed freely in the same setup. It's cryptographically secure against undocumented insertions. And it is very fast.

I find I use it at home now all the time, just to keep track of documents and sync them between computers, because its easier to commit and push to the file server than it is to back it up to the server or save it there.

The drawback is a bit of a steep learning curve, since it breaks all the rules that people are used to with source control, in subtle ways, but its a short steep learning curve.

Improve this answer
5
  • 1
    Git is really good, but (just like everything) it is not the best solution for everyone&everything. programmers.stackexchange.com/questions/111633/…
    – Rook
    Commented Oct 12, 2011 at 3:58
  • 4
    In what way does Git make Mercurial obsolete? Especially in a Windows development environment. It would be better to say DVCS makes other VCS obsolete rather than chucking a petrol bomb & starting a holy war.
    – mcottle
    Commented Oct 12, 2011 at 4:10
  • @mcottle - I wouldn't go even that far. SVN for example is a fine example of quality non-distributed VCS. We can say that SVN makes CVS obsolete, but I'd stop there. Git doesn't in any way makes SVN obsolete - it's a wholly different approach which is good for some, but bad for some other approaches (for more see link above). For example, both Git and Hg relatively "suck" with binary files.
    – Rook
    Commented Oct 12, 2011 at 4:38
  • @ldigas: In what way do git and hg "suck" worse with binary files than svn does? Neither can track changes in binaries beyond per-file granularity, with all associated consequences. Also, they do both make svn mostly obsolete, seeing how either can do exactly what svn does (apart from a few obscure features), and then some; you just have to set it up that way. The best reason for using svn that I can think of is that you're using it already and migrating would be too painful / risky / expensive.
    – tdammers
    Commented Oct 12, 2011 at 5:43
  • @tdammers - I'm not interested in a trolling discussion. For any points above, google a bit and you'll stumble onto something pretty quick.
    – Rook
    Commented Oct 12, 2011 at 10:51
1

Some of the Good practices that we really follow and helped us a lot:

1) Make sure you dont have a writable copy of the file in your local and you always check out to edit. (If at times you have to work local, then try to merge it in source control before EOD.)

2) Label your files periodically, after any small significant milestones.

3) Give good checkout or checkin comments. This will help when you review, sometimes you dont have to open and compare between versions.

Improve this answer
1

how do you manage checkins and prevent feature conflicts and manage dependencies with source control properly?

It is, from my POV, two-factors task: you have to do it from technical (good&easy&bullet-proof branching|merging|audit etc) and management (well established policy "what" "when" "how") sides. Two or even three tiers of separation code in ALM: something like "stable" (passed unit testing), "unstable" (every included feature finished, but app as product have post-integration questions /yes, it can happens/) and "work in progress". This way proper Project Manager can decrease interference of separate developer's work in common.

TFS (which I don't used, use and will not use) have some, AFAIK, fundamental problems in in its aspect of Source Control Management. I just link here to some of James McKay's texts:

Improve this answer
1

A really nice and recent article that plainly and concisely compares and contrasts a few different ways of working with source control is here: Source Control Done Right.

I don't think there's any one strategy/best-practice for using source control. Mature teams that have been working together for a long time have a much less "pain" in this area even if they aren't exactly following popular "best practices".

As for which tools... It almost doesn't matter. What really matters is having everyone on your team be on the same page as far as usage. This means everyone needs to understand how the code line is managed and what they're expected to do. And anyway, in practice you DON'T usually have a choice about which tool to use. Make the best of whatever you're using.

Improve this answer

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.