如何通知其他团队成员重要的项目变更（使用SVN或Ant）？
如果对项目结构进行了重大更改，并且简单的源代码检查无法解决问题，那么我们在项目中具有“changes.txt”文件，该文件描述了需要执行哪些额外操作：
10/10/2010：新表字段，运行以下查询：.....
10/11/2010：库X被替换为库Y，将其复制到tomcat文件夹
这完成了工作，但人们经常忘记检查这个文件并花时间找出它不起作用的原因。
我们的项目是用 Java 编写的，我们使用 Ant 进行构建，使用 SVN 进行源版本控制。
我确信一定有更好的解决方案。我并不是在寻找一些花哨和先进的东西，在 SVN 结帐期间出现一条大红色消息或在 Ant 构建期间出现一些消息就很完美了。
（PS。自动应用更改不是一种选择，某些指令只能由人类执行）
If significant changes are done to a project structure and simple source checkout wouldn't cut it, we have "changes.txt" file in a project that describes what extra actions are required:
10/10/2010: New table field, run following query: .....
10/11/2010: Library X was replaced with library Y, copy it to tomcat folder
This gets the job done but often people forget to check this file and spend time figuring out why it doesn't work.
Our projects are in Java and we are using Ant for builds and SVN for source versioning.
I am sure there must be some better solution. I am not looking for something fancy and advanced, a big red message during SVN checkout or some message during Ant build would be perfect.
(PS. Making changes apply automatically is not an option, some instruction only a human should perform)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
听起来你的团队成员有单独的沙箱。为了知道他们的装备相对于项目是否已经过时，您需要知道哪些更新已在其沙箱中应用（以及哪些更新尚未应用）。
看看您提到的更改，您确实需要在构建发生之前将更改应用于沙箱 - 否则故障模式将是不可预测的，并且可能非常神秘。
也许您可以添加一个 Ant 目标，您的构建将依赖于它，它将检查沙箱是否是最新的，如果不是最新的，则快速失败。
为了确定沙箱是否是最新的，您需要在其中存储某种修订号，该修订号仅在团队成员将其更新为最新时才会更新。当您提到数据库时，如何在其中创建一个简单的表，仅存储代表沙箱状态的数字。您的新 Ant 目标将使用 sql 任务 来获取沙箱修订号，并且将其与源代码树中的文件进行比较（如果数据库路由太复杂，您可以使用不受源代码控制的文件来保存沙箱版本。）如果它们不同，您可以回显一条消息“您的沙箱需要更新，请参阅更改文件并应用比
${sandbox.date}' 更新的更改。一旦沙箱更新，开发人员将需要手动更新数据库表中的记录以使构建正常工作。我强烈建议您编写尽可能多的更改脚本 - 即使更新脚本是手动运行的。
It sounds like your team members have individual sandboxes. In order to know whether their rig is out-of-date with respect to the project you need to know which updates have been applied in their sandbox (and therefore which have not been applied).
Looking at the changes you mention you really need the changes applied to the sandbox before a build happens - otherwise the failure mode will be unpredictable, and possibly very cryptic.
Perhaps you could add an Ant target, which your build would depend on, that would check whether the sandbox was up-to-date, and fail fast if not.
In order to decide whether a sandbox is up-to-date you need to store some sort of revision number in it, one that is only updated when the team member has brought it up-to-date. As you mention a database, how about having a simple table in there that just stores a number that represents the state of the sandbox. Your new Ant target would use the sql task to fetch the sandbox revision number, and compare it to one in the source tree (You could use a file that is not source controlled to hold the sandbox version if the database route is too complex.) If they differ you could echo a message saying 'Your sandbox needs up dating, see the changes file and apply changes newer than
${sandbox.date}'. Once the sandbox has been brought up-to-date the developer will need to manually update the record in the database table to get the build to work.I'd urge you to script as many of the changes as possible - even if the update scripts are manually run.
将其添加到您的 ant 构建文件中的适当位置（可能是最后一个与构建相关的任务，以便人们无需向上滚动即可看到它）：
Add this to your ant buildfile at the appropriate point (probably the last build-related task so that people can see it without having to scroll up):
老实说，在我工作的地方，群发电子邮件似乎很管用。
编辑：这并不意味着您不应该使
changes.txt保持最新。Honestly, mass emails seem to do the trick where I work.
EDIT: This doesn't mean you shouldn't keep
changes.txtup to date.