0

We have a long history of cherry picking changesets between branches with TFVC. I am working hard to change this practice but there is one scenario that I am having difficulty coming up with a clean solution for.

Ideally, a hotfix that is required in production would start its life in the branch that we use for that purpose. A developer would check the changes that should be included in the hotfix into that branch and it should be deployed directly without any need for it to be merged from some other branch first.

In many cases though, it is not clear when the work starts that the change will be included in a hotfix and developers check it into some other branch.

In the past, we would cherry pick this changeset (merge a subset of the changesets that are candidates for merging) through to the branch that we can deploy to production from.

I am wondering what other alternatives that I have.

  1. Manually redo the changes in the target branch? Using copy and paste ideally to reduce the likelihood of merge conflicts that cannot be automatically resolved.
  2. Merge (cherry pick) but somehow remove the [merge] flag so that no merge credit is applied to the changeset. I assume that if I could achieve this then I would get the same effect as in point 1 above without as much risk of errors.

Of the two, the second seems most attractive but I have not so far been able to do this. Here are some things that I tried.

  1. Poking around in the Pending Changes pane in Team Explorer looking for some means of removing the merge credit.

  2. Looked for an option with the tf command line tool. About the closest that I got was the following command which at least let me see that a merge credit would be applied.

    tf vc status /recursive /format:detailed

enter image description here

  1. Shelve the pending changes without preserving them locally. Unshelve the shelveset and drop the merge credit in the process. I started to imagine that this might be an option when I saw the /nomerge option in tf's unshelve command. I have version 15.129.28124.3.

    d:\Projects\Main>tf unshelve /? Microsoft (R) TF - Team Foundation Version Control Tool, Version 15.129.28124.3 Copyright (c) Microsoft Corporation. All rights reserved.

    Restores shelved file revisions, check-in notes, comments, and work item associations to the current workspace or removes an existing shelveset from the server.

    tf vc unshelve [/move] [shelvesetname[;username]] [itemspec] [/recursive] [/nomerge] [/noautoresolve] [/noprompt] [/login:username,[password]]

Unfortunately, this option did not have the effect that I was hoping for - that the merge credit would not be present in the pending changes when I unshelved. The option (and the /noautoresolve option) is strangely not present here either?

https://learn.microsoft.com/en-us/azure/devops/repos/tfvc/unshelve-command?view=azure-devops

Is there any way that I can get this to work? Is there some other approach that would get be the effect that I am hoping for?

Note: Although Raymond Chen covers GIT in his Stop cherry-picking, start merging series, I found it to be quite relevant.

Scott Munro
  • 13,369
  • 3
  • 74
  • 80
  • 1
    I'm curious why you don't _want_ the merge credit - are you merging from your production branch back to your trunk? My naive answer would be to just _do the cherry-pick_, which is what my team does: https://blogs.msdn.microsoft.com/devops/2018/04/19/release-flow-how-we-do-branching-on-the-vsts-team/ very much in opposition to Raymond Chen's thoughts. His are very relevant for the Windows team's workflow, which involves lots of "reverse integrations" and "forward integrations", but poor advice for most people with sensible workflows. – Edward Thomson Feb 08 '19 at 14:39
  • @EdwardThomson Your comment and links are making me think that our long lived Release branch is something we should consider changing. It seemed to fit because we have a web application that only has one version - the current one. Starting a new Release branch for each release to production would mean that we would not need to forward integrate and could side step merge conflicts that happen at that point. – Scott Munro Feb 11 '19 at 09:58
  • @EdwardThomson The motivation for my original question is that changes which later turn out to be required for a hotfix are being made in Development branches and have to be cherry picked into Main (and then into Release under our current setup). It is the merge conflicts when merging Development into Main - having previously cherry picked some changesets - that I am worried about. In general, I guess the scenario is cherry picking where a full merge will follow later. Do you have any tips? – Scott Munro Feb 11 '19 at 10:25

0 Answers0