1

I've always assumed that the output from diff (typically "unified", whether or not it's colorized) is universally understood among most if not all text-based language programmers. Whether it's used due to version control or just comparing two individual files, it seemed that it is rather prolific.

In a recent conversation with a project-partner (who is operating solely in TSQL), they complained that the unified-diff text I sent them in an email (containing literally two changed lines) was unusable/unrecognizable to them. I'm not upset that they aren't familiar with my standard: I'm honestly surprised that "they don't grok diff output".

Questions:

  1. They use Visual Studio and TFS. Some research suggests that TFS does support /format:unified, but I cannot determine if it is default. What is the default, and does TFS have some form of patch.exe to easily import a diff-like change?

  2. They've directed that I send every change as a whole file. Since we both make changes to the code, they then need to manually find my changes and merge them (or not). I understand that this pain is now theirs, but if they choose to not merge because they don't see a change, I am directly affected (and troubleshooting is difficult). Is there a better way I can send them changes so that they easily know where all changes exist yet have the convenience of getting the whole file?

  3. If not diff (or sdiff, vdiff, or diff3), what other "industry-standards" are there? (perhaps limited/focused on MS/TFS)

I'm fairly comfortable with git, GitHub, and GitLab, so my prejudice is recently git-centric, though I have history with RCS, CVS, and Subversion. While I do not assume that git and therefore diff is the end-all/be-all, my point here is not about opinions on VC systems. I'm trying to disspell my mis-assumptions and communicate better.

NB: I have no access to their TFS server, and they will not try to work with my GitLab.

  • You should be able to switch diff tools in your Git client fairly easily and so should they with TFS. If you just want to show them something, go to Tools menu in your client and select their favorite diff tool first. But the bottom line is that if you work on a distributed project it is silly not to have a common version control system that supports distributed development. – Martin Maat Jul 8 '18 at 6:22
  • Anonymous downvoter (aka AC), care to explain? – r2evans Jul 13 '18 at 15:10
2

There is no industry standard.

The diff-and-patch workflow originated in the mid-80s in the context of open-source Unix development. You could send diffs around via email and then apply that patch to your local code. This was influential in the development of version control systems like Git.

Other ecosystems have entirely different conventions. Also, other ecosystems tend to be less text- and command-line oriented than the Unix/Linux/Open-Source ecosystems. Therefore it is a red herring to try to find the command line switch that will make TFS accept your patch.

When working with other people, you will have to negotiate a common workflow. Sending whole files around is the lowest common denominator and isn't necessarily a bad idea – if everyone uses some version control system locally they can copy the file into their source tree and quickly see the changes. In Git you can start a branch off the last common state, apply their changes, and then merge them into your common state to prevent conflicting changes from being silently overwritten.

In such a workflow, the value of sending around patches instead of whole files is quite diminished: while patches let you see the changes at a glance and save you bandwidth and mailbox storage all of that isn't crucially important (as compared to, say, productively collaborating).

I still suggest that you explain every change so that the other party doesn't have to search themselves: a kind if natural-language diff or very detailed commit summary. E.g.: “in foo.sql, I changed the type of the product_category column from varchar to an enum because $requirements”.

  • "if everyone uses some version control system locally they can copy the file into their source tree and quickly see the changes" this is wrong, for that to work base version should be same. – max630 Jul 8 '18 at 7:04
  • @max630 you are right, they will usually see the changes relative to their current state. But as the next sentence in my answer states they can start a branch from the last common state. Sharing whole files isn't the best workflow, but it's sometimes the only one you can agree on. – amon Jul 8 '18 at 7:09
  • 1
    The hard under-truth is I am not convinced that they are using any version control, but that's circumstantial and not wholly relevant to how I should handle the situation (other than to guard against accountability issues with them mis-migrating my changes). – r2evans Jul 8 '18 at 18:48
1

They've directed that I send every change as a whole file. Since we both make changes to the code, they then need to manually find my changes and merge them (or not). I understand that this pain is now theirs, but if they choose to not merge because they don't see a change, I am directly affected (and troubleshooting is difficult). Is there a better way I can send them changes so that they easily know where all changes exist yet have the convenience of getting the whole file?

You could send both old and new version of a file. Though, if you still doubt they can and want to correctly apply your change, you probably should make sure you are not going to be accountable if they do it wrongly. This probably will include negotiating the format of the changes being send and application procedure in more details.

  • Your content about accountability is definitely spot-on. – r2evans Jul 8 '18 at 18:27
  • Both answers are useful and helpful, thanks, unfortunately I can only accept one (an up-vote is still earned). – r2evans Jul 8 '18 at 18:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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