|
⇤ ← Revision 1 as of 2015-10-09 07:11:26
Size: 70
Comment:
|
Size: 1941
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| Wow, such merge driver, very plan. | #pragma section-numbers 2 = Working Copy Sync Plan = |
| Line 3: | Line 4: |
| (This will be filled in soon.) | <<TableOfContents>> == The Problem == It is somewhat common in the real world to have ''generated files'' alongside source files in the working copy. When a merge happens, generated files that are modified on both ends are likely to cause rebase conflicts. The best way to resolve these conflicts is usually to regenerate these files, and that's what developers have to typically do by hand. === But isn't checking in generated files bad? === While there are a lot of ways checking in generated files is bad, there are also valid use cases for it. For example: * These files change relatively rarely for individual developers but often enough in the aggregate to be a problem. * These files take a long time to generate but the resultant artifacts are small. * These files capture the state of the world they were created in (e.g. databases) in important ways. That state of the world can change such that the files can no longer be generated again. * Serving these files via an out-of-band mechanism like an artifact server is not feasible, or much more work than just serving them via Mercurial. * While the files could be generated by a build system, the project really has no need for a build system outside of these generated files, and would like to keep fast iteration cycles by avoiding build steps. Each of the above points has been true for at least one repository at at least one large organization. Ultimately, software engineering is often about tradeoffs, and in some cases checking in generated files is the right tradeoff to make. This feature will make working with such files less painful. === Doesn't the merge tool support already in Mercurial solve this problem? === == The Solution == Add support to Mercurial for custom ''merge drivers''. A ''merge driver'' is an in-process hook that controls the overall merge process. |
Working Copy Sync Plan
Contents
1. The Problem
It is somewhat common in the real world to have generated files alongside source files in the working copy. When a merge happens, generated files that are modified on both ends are likely to cause rebase conflicts. The best way to resolve these conflicts is usually to regenerate these files, and that's what developers have to typically do by hand.
1.1. But isn't checking in generated files bad?
While there are a lot of ways checking in generated files is bad, there are also valid use cases for it. For example:
- These files change relatively rarely for individual developers but often enough in the aggregate to be a problem.
- These files take a long time to generate but the resultant artifacts are small.
- These files capture the state of the world they were created in (e.g. databases) in important ways. That state of the world can change such that the files can no longer be generated again.
- Serving these files via an out-of-band mechanism like an artifact server is not feasible, or much more work than just serving them via Mercurial.
- While the files could be generated by a build system, the project really has no need for a build system outside of these generated files, and would like to keep fast iteration cycles by avoiding build steps.
Each of the above points has been true for at least one repository at at least one large organization.
Ultimately, software engineering is often about tradeoffs, and in some cases checking in generated files is the right tradeoff to make. This feature will make working with such files less painful.
1.2. Doesn't the merge tool support already in Mercurial solve this problem?
2. The Solution
Add support to Mercurial for custom merge drivers. A merge driver is an in-process hook that controls the overall merge process.