Some version control tools (including Git, for example) implement rename and move informally, by deleting the file and adding a new one with the new name or path.

Veracity implements rename and move formally. When a file is created, it gets a unique identifier which never changes and which is distinct from its name or path.^[28] Regardless of what happens to that file, its identity stays the same. If and when it gets modified, moved, renamed, or deleted, it is still the same file it was when it was born.

Some people prefer informal rename. They consider it somewhat easier to use.

I, however, am not a fan of informal rename. Some VCS operations, including the merging of branches, need to preserve the identity of a file across a change of its name. To accomplish this, Git has to do some educated guesswork. When Git sees a deleted file in one revision of the tree and an added file in another, it compares the contents of the files to decide if in fact they should be considered the same file. Git’s implementation of this guesswork is actually quite clever, usually producing the result the user expects. But not always. I personally prefer a design which allows the user to record exactly what happened, rather than expecting the VCS to divine the user’s intentions later. The design of Veracity reflects my preference on this matter.^[29]