Comment by PuercoPop
10 years ago
Something I'm wondering and the man page doesn't clear, does it track files across renames or does it only track content like git?
10 years ago
Something I'm wondering and the man page doesn't clear, does it track files across renames or does it only track content like git?
It tracks renames, it's not like git. Every file has an internal identifier, that's the actual file id, the name is a versioned attribute of the file.
What's not clear from your replies is whether it tracks renames like mercurial, by having users run a manual command to ensure the VCS know about the rename. Except if bk has a file system monitor, I'll assume that's what it does. Unfortunately, data on a few Mercurial repositories I looked at (Mozilla's and Mercurial's) shows that people don't mark all file renames.
The only way I'm familiar with instructing mercurial to do this is with
Is there another way to indicate a rename?
How does it detect renamed files in the filesystem?
Thank you for open sourcing by the way, I can definitely see how some features (binary file handling, submodule handling) could be useful for large-scale projects like games.
Each history file contains it's internal name, much like a file system has an inode # that is the internal name for that file. We call the names "keys" and you can dig out the inode key like so (every delta has a key, the first delta is called the rootkey):
The key is user@host|relative path|UTC|checksum|64 bits of /dev/random and they are guaranteed to be unique if your DNS config is correct (we don't create duplicate keys, look for the uniq db in the code).
The way we version the entire tree is simple, it's logically (implemented differently for performance):
where each rootkey uniquely identifies a file and each delta key identifies the tip as of that commit.
Not sure if that is clear enough or not, ask away if not.
5 replies →
Yes, files are tracked as first class objects as they are renamed.