Tuesday, September 13, 2005

The Achilles heel of DRCS

One of the things that most distributed revision control systems do is that they keep a permanant, indefinite record of everything that's ever happened to a branch. This can be useful if some company in Santa Cruz decides to defame you or your company. Most of the time this older information is unnecessary baggage that is essentially kept around just in case its ever needed.

This is the achilles heel of distributed revision control. As time passes the storage of past events grow indefinitely and become unwieldy to work with. Some tools, such as bazaar-NG, are working to address certain aspects of this.

Whats needed is a way to conflate history by merging together old revisions. By conflating revisions a bit of disk space is saved, network access is reduced and the amount of work involved in building by using ancestors is reduced.

Consider, for example, some sort of pool of patches. If the access to these patches is monitored then one can detect which patches are no longer very interesting. If two non-interesting patches are next to each other, then merge them into a single superpatch.The two patches in the pool can then be removed.

As time passes older, unused patches will continue to clump together. These multipatches can be used in the place of the individual patches in any place that all of them would have been applied anyways.

If the user wants a revision that has been merged into a multipatch, just go ahead and get it and add it to the pool. It can be munged with other patches just as with prior events.

0 Comments:

Post a Comment

<< Home