使用 Eclipse 和 CVS 管理依赖关系
我有一些 dll 的代码，Eclipse 中的两个或多个项目都需要这些代码。 目前，每个项目都有一份代码副本并单独构建 DLL。 我想将 dll 代码分离到一个单独的 eclipse 项目中，以便有一个公共位置。 但我想避免这样一种情况：我们必须在一个项目中构建 dll，然后将 dll 复制回其他项目，并检查每个项目的 dll。 这将为每个项目创建一个 dll，该 dll 无法追踪到构建该项目所用的确切代码。
有没有办法以某种方式将 dll 符号链接到另一个使用 CVS 作为版本控制系统的 eclipse 项目，以便可以知道使用哪个版本的代码来创建 dll？ 我是否让这个变得太复杂或遗漏了一些明显的东西？
我考虑过 Eclipse 包管理器中的工作集，但我必须更多地研究如何将它们与 CVS 一起使用，以避免让下一个检查它的人成为噩梦，并且无法弄清楚为什么他们的项目不会'编译。
谢谢。
I have a bit of code for a dll that is needed by two or more projects in eclipse. Currently each project has a copy of the code and builds the DLL separately. I want to separate the dll code into a separate eclipse project so there is a common location. But I want to avoid the situation where we have to build the dll in the one project, then copy the dll back to the other projects and check the dll to each respective project. This will create a dll for each project that isn't traceable to the exact code that it was built with.
Is there a way to somehow symbolically link the dlls to another eclipse project that is using CVS as the version control system so that it is possible to tell which version of the code was used to create the dll? Am I making this too complicated or missing something obvious?
I thought about working sets in the package manager for eclipse, but I have to investigate more on how to use them with CVS to avoid making it a nightmare for the next person who checks it out and can't figure out why their project won't compile.
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
在单独的项目中创建一个新文件夹怎么样？ 在创建新文件夹的高级部分中，有一个选项可以链接到文件系统上的另一个位置。
或者，您也可以创建一个使用projectset.psf 文件的容器项目。 将项目集文件链接到存储库中的不同项目。 当您想要签出该项目时，请签出容器并右键单击项目集文件并选择导入项目集...
What about creating a new folder in a separate project. In the advanced section of creating a new folder there is an option to link to another location on the file system.
Or you could also create a container project that makes use of a projectset.psf file. Have the projectset file link to the different projects in your repository. When you want to check out that project, check out the container instead and right click on the projectset file and select Import Project Set...
如果您使用一个工作区，则最终会得到三个项目，每个项目都在 CVS 中镜像：一个是 dll，其他是使用 dll 的项目（配置为这些项目对 dll 项目的项目依赖项）。
对于三个项目，我不会以工作集为目标 - 它们非常适合在一个工作区中管理大量项目，对于三个项目，我认为它们太过分了。 我通常倾向于多个工作空间而不是工作集。
关于下一个人处理这些项目：您需要保留某种有关如何设置项目的文档。 您可能会说您的 eclipse 项目文件就是这样做的（因为它们定义了对另一个项目的项目依赖），但这是针对机器的 - 人类往往喜欢其他通信方式。
如果您担心对 dll 的更改与一个项目不兼容（因为应用这些更改的人不关心其他项目），请瞄准构建服务器。 每当版本控制下的某些内容发生更改时，这将构建所有项目和依赖项目，运行所有测试，提供内部版本号并将其全部打包以供使用。 这样您就可以确保 - 无论您的可交付成果中的内容 - 都可以重现，因为构建服务器无法对代码进行本地（未提交）更改。 此外，构建服务器会在最后一次提交时（好吧 - 几分钟后）发出失败信号（要么是损坏的 API，要么是损坏的测试），并将修复损坏的负担交给造成损坏的人。
If you are working with one workspace, you end up with three projects, each mirrored in CVS: One is the dll, the others are the projects using the dll (configured as a project dependency of these projects upon the dll project).
With three projects I wouldn't aim for working sets - they are good for managing a lot of projects within one workspace, for three projects, I'd consider them overkill. I usually tend to aim for several workspaces instead of working sets.
Regarding the next person working with these projects: You need to keep some kind of documentation about how to setup your projects. You might say that your eclipse project files do just that (as they define a project dependency upon another project) but this is for the machine - humans tend to like other communication means.
If you are worried about changes to the dll being incompatible to one project (because the person applying these changes doesn't care about the other project), aim for a build server. This will build all projects and dependent projects whenever something under version control changes, run all tests, provide a build number and package it all ready for use. This way you can be sure that - whatever is in your deliverable - can be reproduced, because the buildserver is not able to make local (uncommitted) changes to the code. Also a buildserver will signal failure (either broken API or broken tests) at the moment of the last commit (well - a few minutes later) and place the burden of repairing the damage on the one causing the damage.