Contents
Incorporate Simple 3-way Merge in Main-line Vesta Release
We already have a usable 3-way merge tool. It's build on top of the 3-way merge command-line tool that's packaged with RCS. While it's far from perfect, it gives Vesta merging capability similar with CVS or Subversion.
The trouble is, this merge tool is a Perl script written using the SWIG interface to the Vesta APIs. In order to make it useful for the general public, we need to do one of two things:
- Package the SWIG interfaces for installation like the rest of Vesta (in .rpm/.deb form) and gnerally figure out how to make them work in more environments with more different versions of the scripting languages they target.
- Re-write the vmerge tool in C++.
Option #1 is defintiely better, as it will have other benefits (like making it possible to write other scripts using the SWIG interfaces, such as an improved vestaweb. However, it might be a bit more complicated. It might be best to facilitate building the SWIG itnerface outside of Vesta (rather than making many more std_envs for different versions of different Linux distributions and other operating systems). This might mean package the Vesta libraries and their headers for use outside Vesta. This could also tie in with using autoconf to build Vesta outside Vesta.
On the other hand, making a Perl script part of the Vesta core adds a dependence on an external piece of software. Re-writing vmerge in C++ might make it simpler to support more operating systems. Of course to really make it portable we shouldn't be calling out to the merge(1) command that comes with RCS to do the work. (I have several times heard other revision control authors mention eliminating dependencies on external programs as common as diff(1).)
Fix Bugs and Add Features Related to Merging
There's a lot of little issues related to merging which we need to deal with:
We plan to base several merging related capabilites on triggers, which need to be completed.
vcheckin gets old-version wrong in some cases. This causes confusion about the ancestry of versions, which is informaiton needed for merging. The current vmerge script has a partial work-around for this problem, but we should really fix it.
We'd like the repository to record renames. This is needed to support merging across a rename operation, which is one of the tricky merging cases. (Note that our plan is to use triggers for part of this.)
Merging needs to traverse the ancestry of versions being merged. We may need to add a method for the replicator to follow the old-version attributes to determine what to replicate. Or maybe we should have a utility program which generates replicator instructions with a method like this.
We want a vundo/vrewind command to back up the state of a working directory to the point before a merge operation was performed. (This is described in the merging RFE.)
@@@ Add more stuff here
Improve Basic 3-way Merge Capability
There are several things which we could do with 3-way merge that the current one doesn't:
Once we have triggers, we can implemented the recording of past merges performed as described in the merging RFE.
- With records of past merges, we can avoid merging the same thing twice, by treating past merges as common ancestors.
Once the repository records renames, we can add merging across renames.
@@@ Add more stuff here