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. Disadvantages: 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 branches? Tony