Merging In Vesta
Most people consider "revision control" to about more than simply storing the state of files at different points in time and keeping track of who made which changes, when they made them, and which version each version is derived from. Most people consider merging of changes made in parallel to be an integral part of revision control.
For most of Vesta's history, we've thought that the repository's filesystem interface was sufficient support for this, because the user can run any tools they like to compare existing versions and modify their working copies. While it's true that the filesystem interface gives users flexibility to use a variety of merging and conflict resolution tools, they really need more assistance than that.
- Merging requires an understanding the ancestry of the different versions. Users shouldn't be forced to work that out themselves. The system should automatically use the ancestry information that it records as versions are created.
- Merging directories (as with Vesta packages) requires recursively processing changes to the files and subdirectories they contain. This is best automated, and is error prone if users do it by hand.
Cases where branches diverge for significant periods of time are usually more difficult to merge. Simple merging tools (e.g. RCS/CVS-style 3-way merge) produce more conflicts when merging between long-lived divergences, requiring user intervention to resolve the differences. Many modern systems emphasize automatically detecting and handling more cases to avoid false conflicts, allowing the user to spend more of their time dealing with true conflicts.
There are also a variety of subtle and complex merging problems, including:
- A user might merge in a change that adds some lines, and then later delete those lines. It's often unclear whether this should be treated as a deletion of the new lines (i.e. moving forward) or undoing the addition of those lines (i.e. moving backward by reverting a change).
- A file may be renamed in one branch, and modified in another. In such cases, it's desirable to merge the modifications into the new filename. this requires some form of rename tracking.
A user may only want to accept a portion of the changes made in another branch. This is referred to as cherry picking. (This may not seem like a merge issue, but it does involve where a change originated, and is thus an issue of ancestry.)
/Food4Thought contains a collection of information which may be helpful to people thinking about the merging problem. If you haven't spent time thinking about it before, start here.
/DevPlan contains a more concrete description of:
- Where Vesta merging is today
- Where it's headed
- How we'll get there