Renames are a thing and git made the wrong choice there. It's not like we are perfect but we are way closer.

So on versioning changesets I didn't really explain. Lemme try again.

In any DVCS you have a bill of materials, that's what describes the tree. Git's is different than ours because they don't version files, we do. So our bill of materials looks like:

  path/to/file <version>
  path/to/different_file 1.1
  path/different_dir/a_file 1.19

If you "cat" the changeset file as of any version you get what the tree looks like, a list of files and a list of revisions.

Of course it doesn't work like that because, um, reality and merges and parallel development. We have UUIDs for each file and each version so it looks like

UUID_for_a_file UUID_for_a_version

and our UUIDs are pretty sweet, not sha1 or some other useless thing, they are

user@host|path/to/where/it/was|YYYYMMDDHHMMSS|checksum

those are for each node in the graph, for the very first node which is the UUID for the file, there is a "|<64 bits of /dev/random>" appended.

So the changeset file is just a list of

UUID UUID

Not sure if that helps.

The benefit of versioning the file that holds all that data is we can use BK to ask it stuff. Want to see the history of the repo? bk revtool ChangeSet Want to see what files changed in a commit? bk diffs -r$commit ChangeSet Yeah, we have to process all the UUIDs and turn them into pathnames and revisions but we can do that and do it fast. So it works.

All the tools we built to look at stuff can look at the metadata. That's worked out well.