[cvsnt-dev] Random thoughts - changesets

Tony Hoyle tmh at nodomain.org
Tue Mar 23 22:37:33 GMT 2004

Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.

Storing changests is kind of interesting, as it solves the generic rename 
problems in a really nice way.

Basically instead of storing changes to the files, you store them as changes 
to the entire repository (essentially entire-repository diffs, but optimised a 
bit so you can actually get at individual files if you need to).

The advantages:

1. Nice rename support.  Nothing really special needed for add/remove.
2. Relatively easy to implement... you could knock up a proof of concept in a 
couple of hours with a perl script (you could almost do it with diff --recurse)
3. Distributed repositories become trivial.


1. Positive deltas (there may be ways around this though).  If you have 1 
million revisions based on a single baseline it's going to take a long time to 
do a checkout :)
2. It's *really* hard to locate a revision.  Let's say you wanted revision 1.1 
of the file /a/b/c from about a month ago.  In the meantime /a was renamed to 
/d, and /g was then renamed to /a, and /b was renamed to /d... however /c is 
now under the new /a.  How do you find it, short of a brute force search of 
the entire reopsitory?
3. One of the nice things about CVS is its virtually freeform tagging.  The 
tag 'foo' can refer to lots of revisions of files on different branches, all 
created at different times... this usage is unusual (I'd wager most people 
just tag from the root just bfore release) but still useful.
4. Similar to (3), a directory can contain files from many branches.  Let's 
say I have a directory a, containing files from branches foo, bar, and baz, as 
well as HEAD.  I then rename a to b.  What happens to the files from the 


More information about the cvsnt-dev mailing list