每个应用程序工作副本是否应该有自己的库项目工作副本？
让我们假设一些名为 Graphics、Sound、IO 等的共享库项目，以及使用这些项目的多个应用程序。 一个 WC 用于共享项目，一个 WC 用于每个应用程序，哪一个最好？或者每个应用程序都有一个 WC 和一个用于库的不同 WC？
之间的区别
src
|
|---libs
| |
| |---graphics
| |---sound
| |---io
|
|---project1
|---project2
即：和：
src
|---project1
| |
| |---libs
| |
| |---graphics
| |---sound
| |---io
|
|---project2
| |
| |---libs
| |
| |---graphics
| |---sound
| |---io
我可以看到每种情况的优点，但我认为现实生活的经验在这里会非常有帮助。
Let's assume some shared library projects called Graphics, Sound, IO, etc, and multiple applications which use these.
What's best, one WC for the shared projects and one WC for each application? Or each application has a WC and a distinct WC for the libraries?
I.e. the difference between:
src
|
|---libs
| |
| |---graphics
| |---sound
| |---io
|
|---project1
|---project2
And:
src
|---project1
| |
| |---libs
| |
| |---graphics
| |---sound
| |---io
|
|---project2
| |
| |---libs
| |
| |---graphics
| |---sound
| |---io
I can see advantages in each case but I think real-life experience would be really helpful here.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我建议将这些库作为自己的项目......
并且要在项目中使用它们，您应该 svn:externals 将 io、图形等链接到特定项目，这可以防止将源代码复制到每个项目，并且您有一个点可以修复错误并进行增强等。
I would suggest to make the libraries to be their own projects....
And to use them inside the projects you should svn:externals to link io, graphics etc. to the particular projects which prevents copying the source code to every project and you have a single point where you can fix bugs and do enhancements etc.
如果这些库在整个代码库中复制，它们将以什么方式“共享”？
您认为在应用程序目录下放置库有什么优势？
In what way are these libraries "shared" if they're copied around all over the code base?
What advantages do you see for having libs under the app's directory?
除非您有充分的理由支持所有应用程序的库的不同 WC，否则我建议为库使用一个 WC - 这样更容易维护库（更新、构建）。
支持不同库 WC 的原因可能是特殊的稳定性要求，并且仅在需要时才迁移到某些库的新版本。
Unless you have good reasons for supporting distinct WC of the libraries for all applications I would recommend using one WC for the libraries - it's easier to maintain the libraries this way (update, build).
The reasons for supporting distinct library WCs could be special stability requirements and moving to new version of some library only when it's needed.
您是否考虑过使用 Maven 存储库来存储二进制依赖项，而不是源代码控制系统？
然后，可以使用像 ivy 这样的依赖管理器将 jar 下载到 WC 中，作为构建过程的一部分。
Have you considered using a Maven repository to store your binary dependencies, instead of a source code control system?
Dependency managers like ivy can then be used to download jars into the WC as part of the build process.