5 ms·

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?

wscott 10y ago
Yes, files are tracked as first class objects as they are renamed.
luckydude 10y ago
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.
- hansihe 10y ago
  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.
  - luckydude 10y ago
    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): $ bk log -nd:ROOTKEY: -r+ slib.c lm@bitmover.com|src/slib.c|19970518232928|52808|f3733b2c327712e5 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): <rootkey> <delta key> <rootkey> <delta key> ... 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.
    - 4ad 10y ago
      What happens when you duplicate a file? Does it track history back to the original parent? Can it help with future merges?
      - luckydude 10y ago
        You mean copy the file? There is a bk cp command that copies the file and gives it a new rootkey. But from that point on the history of the two files diverge.
        4ad 10y ago
        Yeah, copy. I see, thanks.
    - danielbot 10y ago
      Not tracking namespace accurately is Git's biggest weakness and would most probably be BK's best argument for getting a tryout. With Git, renaming a file and editing it at the same time tends to make a mess of the history and cause much pain. You can say just don't do that, but I say it happens, and it should just work.
      - luckydude 10y ago
        That and a UI that is uniform and sub-modules that work correctly and a system that doesn't let you do things that mess up your data. Oh and blame that is fast: $ time bk annotate slib.c | wc -l 18508 real 0m0.031s
- glandium 10y ago
  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.
  - neandrake 10y ago
    The only way I'm familiar with instructing mercurial to do this is with hg addremove -s Is there another way to indicate a rename?

wscott 10y ago

Yes, files are tracked as first class objects as they are renamed.

luckydude 10y ago

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.

hansihe 10y ago
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.
- luckydude 10y ago
  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): $ bk log -nd:ROOTKEY: -r+ slib.c lm@bitmover.com|src/slib.c|19970518232928|52808|f3733b2c327712e5 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): <rootkey> <delta key> <rootkey> <delta key> ... 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.
  - 4ad 10y ago
    What happens when you duplicate a file? Does it track history back to the original parent? Can it help with future merges?
    - luckydude 10y ago
      You mean copy the file? There is a bk cp command that copies the file and gives it a new rootkey. But from that point on the history of the two files diverge.
      - 4ad 10y ago
        Yeah, copy. I see, thanks.
  - danielbot 10y ago
    Not tracking namespace accurately is Git's biggest weakness and would most probably be BK's best argument for getting a tryout. With Git, renaming a file and editing it at the same time tends to make a mess of the history and cause much pain. You can say just don't do that, but I say it happens, and it should just work.
    - luckydude 10y ago
      That and a UI that is uniform and sub-modules that work correctly and a system that doesn't let you do things that mess up your data. Oh and blame that is fast: $ time bk annotate slib.c | wc -l 18508 real 0m0.031s
glandium 10y ago
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.
- neandrake 10y ago
  The only way I'm familiar with instructing mercurial to do this is with hg addremove -s Is there another way to indicate a rename?