Marginal features

There are basic features which any version control system should have -
add, delete, and rename files, probably add, delete, and rename of
directories, and of course modify files. As I mentioned in another post,
I'm now fairly convinced that moving lines within a file should NOT be
supported by a version control system, at least not one which is strictly
line-based.

Then there are the marginal features, which might or might not be good
ideas, here are some of them -

moving the root - the easiest way to provide directory rename
functionality is to treat the root as special. We implemented it this way
in Codeville, and didn't think much of it, but it turns out that precisely
this functionality is needed to import one project into another one as a
subdirectory, so we now think this functionality is a good idea and will
be supporting it in the future

splitting and suturing - There are really two versions of this: copy and
un-copy, and cut in half and sew together. Copying is quite broken from a
merge standpoint - what copy should changes be merged into? so nobody
supports it. Un-copy is reasonable in principle, but lacks an inverse
operation and has lots of wacky edge cases. We aren't going to be
supporting it in Codeville, but we may have a fake 'suture' command which
canonically picks one of two files to delete, in case the same file was
made twice and you want everyone who fixes the merge conflict to delete
the same version. Just randomly deleting one could result in a clean merge
of two different people deleting different versions, and that would be
bad. Come to think of it, maybe we could record the suture in the history
and treat deletion of the other version without the suture present as a
conflict. Hmmm.

Anyhow, cutting in half and sewing together are somewhat more reasonable
in principle than copy and un-copy. With a weave, sewing together is
restricted in that only one of the two orders of sewing together can be
supported, but with our fancy clumping weave ordering algorithm the A then
B version is supported quite well. Perhaps there could be a command to sew
together two files and have the system pick the order. Cutting in half
doesn't have the same problem, because you can place the two halves in the
correct places. There is a fair amount of complexity added by this
functionality though, and its usage in the real world is quite rare, so
for now it's in the 'probably not' pile.

convergence - If two people apply the same patch from outside of the
system, it would be nice if applications of that patch were treated as the
same thing, which would happen if they were both done within the same
version control system. Likewise if two people do an initial checkin of
the same stuff it would be nice if their projects could simply merge
together cleanly as if they started from the same initial checkin. This
functionality is quite fragile though (initial checkins may be of slightly
different versions, patches applied have to be *identical*) and it's quite
technically difficult to support, so for now not only doesn't Codeville
have much of this, but what little it does have is probably going away.

resurrection - If a file is deleted, should it be possible to un-delete
it? In principle it seems like the answer should be yes, but changes which
are merged in after a file is deleted aren't forced to not conflict, so
the corpse might be fairly rotten if you just bring it back. With a weave
we can simply take whatever the default forced merge is and display that.
It may break the build, but it should be fairly readable. At the moment
we're leaning towards allowing that with a strong warning about how the
user should look over the file carefully in case something got broken
while it was dead. "Oh yeah, they're dead. They're all messed up."

Finally, there are features which are clearly a good idea but we're
putting off for a future release because new architecture will have to be
done to support them. These include selective update, cherry-picking, and
undo/rollback. I've put a lot of thought into these, and I *think* I know
generally the right approach to take, but we definitely aren't ready to
just go ahead and implement them yet, especially with the big reworking to
use weaves coming up. It's hoped that that reworking will make these
features easier, rather than harder. It certainly makes per-hunk ancestors
easier.

-Bram