-
Notifications
You must be signed in to change notification settings - Fork 534
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Dlib as (forked) surepo, transplant your changes to your forkadd it as subrepo, #210
Comments
There isn't any reason to update the copy of dlib used by mitie. |
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? |
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. |
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. |
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.
The text was updated successfully, but these errors were encountered: