Best practices for developing and using common libraries in version control?
I've always wondered how an actively developed common library used in two or more projects should be stored in version control. I imagine it can be handled differently than a third-party library, since an in-house library is more likely to get hot fixes that should be distributed to many of the projects in version control.
Should its binary files be imported into the projects that use it as it is updated (pretty much like a third party library), or could its source code be checked out together with the projects? Is it possible to have references to other version controlled paths in Subversion or other version control systems?
I'm working in a project now that has common libraries that reside elsewhere in Subversion (and used in many projects) checked in with the project, so any changes made to them in this project are not reflected in their "real" repository. I'm going to suggest some changes to this, but I would like some thoughts on what the best practice for handling these common libraries is.
As others have already mentioned, SVN's externals are a good way to do this. Through them you can reference other parts of your repository (or other repositories, too, FTM). A project can reference the head of some other (library) project or some branch or tag. The latter two make for stability, the former one for always being up-to-date with the library.
I've seen various schemes along these line using CVS (no externals here, so it was checked-in scripts that had to be executed) and SVN. In the company I'm working now we have different top-level folders for projects and shared libraries. The projects can refer the libraries. On the project's trunk these external references usually are to the libraries' heads, on tags and branches projects refer to libraries' tags (or, sometimes, branches).
如果使用Subversion，我会使用svn：externals，它允许您创建一个Subversion repo到另一个的依赖关系。
Subversion does allow you to have references to other paths, through the use of the svn:externals property.
That said, often you will want a little bit more control over the state of a project than just "take whatever is in the shared library head". In that case, I would suggest committing the compiled library binary into each of the other projects that uses it. That way, you have control over deploying the library to each of its clients.
链接地址: http://www.djcxy.com/p/37526.html下一篇: 在版本控制中开发和使用通用库的最佳实践？