On 6/30/2016 5:20 PM, Robinson, Paul via cfe-dev wrote: > We were using tags for a while in our own SVN->git conversion internally. > (git branch is pushed to SVN and the SVN r-number used to create a tag.) > They are convenient for some things, but each tag adds a new (if small) > file to .git/tags and I don't know that it really scales well when you > are talking about (long term) hundreds of thousands of them. That was > not what tags were designed for.
We're using tags in this manner for our internal repos and LLVM/Clang mirrors and haven't experienced any problems. We're at ~50k tags for our most used repo, so not quite at hundreds of thousands yet. When I look in .git/refs/tags of one of my repos, I do *not* see 50k files; I see ~400. I'm not sure what causes some to appear here and others not. I don't see how this use of tags is not representative of what tags were designed for. They are designed to label a commit. That seems to match well what is desired here. > We've since stopped creating the tags, and gotten used to not having > them. We do the 'rev-list --count' trick which mainly gets recorded as > one component of the version number, and it has been working for us. As I understand it, 'git rev-list --count HEAD' requires walking the entire commit history. Perhaps the performance is actually ok in practice, but I would be concerned about scaling with this approach as well: $ time git rev-list --count HEAD 115968 real 0m1.170s user 0m1.100s sys 0m0.064s > I think having the number in the commit log (even if it's just for the > superproject) would be preferable. You can use 'git log --grep' to > find a particular rev if you need to. Grepping every commit doesn't seem like the most scalable option either. I did a quick test on a large repo. First a grep for an identifier: $ time git log --grep <id> ... real 0m1.450s user 0m1.340s sys 0m0.092s Then I did the same for the associated push tag: $ time git log -n 1 <tag> ... real 0m0.048s user 0m0.024s sys 0m0.016s Tom. _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
