Dlib as (forked) surepo, transplant your changes to your forkadd it as subrepo,

[s-hemer]

I'd suggest to better keep track of dlib improvements, fork dlib, transplant your changes/improvements to your fork, and add it as subrepo. Holding a copy is not the fine way of SCM.

[davisking]

There isn't any reason to update the copy of dlib used by mitie.

[s-hemer]

Would not #85 be one such reason? And things like proper installation/packaging? Did not use MITIE but came across that because a colleague asked for such a system-wide install (Ubuntu). At least, using a fork or branch (did not check that you are also main dlib contributor) as a sub-repo would be, at least to my understanding, the more accurate way of using SCM tools like Git, or?
Was only a suggestion out of the mentioned reasons. Sad that you just closed with such a undifferentiated remark.

[davisking]

Still, the version of dlib in MITIE is fine and there are no users who are impacted by anything that would be fixed by updating. Moreover, it would not surprise me if there are still users who use MITIE on really old compilers who would be negatively impacted by such an update.

Also, the reason MITIE doesn't use dlib as a git submodule is because I know from experience that many of the users of MITIE are not familiar with git. Git submodules in particular would be confusing to some of them since there is a two step clone procedure. Instead, MITIE uses git subtrees to handle the dlib dependency which is transparent to users. It's all under SCM. It's not some kind of adhoc copy.

[s-hemer]

Hey Davis, thanks for pointing that out. Indeed, I was only aware of submodules (which I misleadingly called subrepos). For me, they provide the more clear way to see at which rev the other module is to be used (so I am totally fine with pinning it to a not-up-to-date revision) but ok that's a matter of taste. In the end, that is a differetiated answer, I can totally live with.