Encapsulating "proposed" code changes in a file for use with windiff (for code review purposes) [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. Closed 10 years ago.

I've seen this being used within big software companies where they had their own system to implement this. The developer who wanted to make a checkin would first create a self-extracting "pack" that other developers could open on their systems开发者_C百科 and see what the changes to the system would be (keeping in mind the "base" version of the code file + the changes proposed). [Think a portable file showing windiff versions of whatever you're planning to commit]

That way, other developers could see the proposed code changes, review them / suggest changes, etc.

I'm not able to locate something like this in the open source world. Can folks suggest something here?

---

a DVCS (Git or Mercurial) is quite adapted to that scenario in that:

• the developer can make all the commits he/she wants in the local repo
• other developer can just fetch (not merge) the changes from the first developer's repo, and compare them (like for instance in the question "How to view diff of a forked github project".

Even if a fetch is not possible, the first developer can generate patches that can then be examined, like the "pack" you describe in the question.
Actually the git format-patch man page mentions:

--no-binary

Do not output contents of changes in binary files, instead display a notice that those files changed. Patches generated using this option cannot be applied properly, but they are still useful for code review.

That confirm the usage of those patches for code review.

An open-source project which can use those kind of patches would be Review Board.
Gerrit has also a similar mechanism as illustrated in the Egit review process.

---

If you're using Subversion, then you have a couple of options:

1. Make your changes in a branch, get people to review the log for that branch and decide on a merging strategy.
2. If you're not making huge changes, then don't commit - create a patch file instead that you can send to your colleagues. They can apply that patch to a working copy and review the changes made before committing. This is the typical approach to contributing to open source projects when you're not a committer on the project.

---

If you are not very particular about a self extracting tarball. Here is some quick review of opensource tools available.

http://ostatic.com/blog/open-source-code-review-tools

I use reviewboard and its latest version is pretty good.