问题标签 [versioning]

我正在使用需要对文档进行版本控制的系统，例如 CMS。
用它的表为它创建数据库的最佳实践和方法是什么？

在我的应用程序中，人们将上传简历，他们可以更新我存储的简历。简历使用数据库中的文件流。那工作正常。但现在我想跟踪上传简历的版本以查找最新和以前的简历。

做这个的最好方式是什么？

我一直理解版本中的每个数字（例如：1.2.3.4）都被视为常规 int 值。我们正在使用一些遵循不同约定的第三方 DLL，这似乎会导致我们的修补过程出现问题（补丁不会用新的 DLL 覆盖旧的 DLL）。

DLL的旧版本是1.38 DLL的新版本是1.4

我理解事情是 1.4 < 1.38。我会亲自使用1.40。他们声称 1.4 == 1.40。

我讨厌因为无知而犯错误，我也讨厌盲目地遵循约定而不理解它们背后的含义。所以现在是我要求澄清的时候了。对此有何看法？

我想知道是否有一种方法可以在不使用 BuildNumberOverrideTarget 的情况下同步内部版本号（20080213.1），而我必须生成自己的内部版本号？我基本上想使用默认/内置的 tfs buildnumber 生成器，但想访问它以使我的程序集版本与之对齐。可以这样做吗？这样做是否明智？

只需添加一个零，如下所示

结果为 2.3.406.2

这不是我想要的。

所以这可能是不可能的？

我有一个使用 2.0 框架的大型 .NET 远程处理项目。服务器的 API 通过接口公开，共享类型包含在与客户端应用程序共享的程序集中。

我有一些方法可以接受基类的数组，该基类有许多不同的类继承自它。

例如，我有一个基类“Vehicle”，它有两个继承自它的类，分别是“Car”和“Truck”。

我有一个方法 IFoo.Save(List 车辆)

稍后，我添加了一个从名为“Motorcycle”的“Vehicle”继承的新类，并且只有服务器或客户端具有新的共享程序集，但不是两者都有。其中一个将无法解析新类型。

你觉得处理这种情况最灵活的方法是什么？

编辑：这是一个 Windows 窗体客户端应用程序和托管在 Windows 服务中的远程服务器。

我工作的团队仍然使用SUN Teamware进行源代码管理 (SCM)。我已经使用它一段时间了（超过 10 个月），我对它没有任何特别的抱怨。

Teamware 已被用于管理 Sun 最大的源代码树，包括用于 Solaris 操作系统和 Java 系统的源代码树，并且运行良好。但它也是一个已经停产的旧商业（闭源）产品。这是 Sun 将其代码库转换为开源社区的过程的一部分，这反过来又导致转向更新的版本控制系统，例如 Mercurial。

这让我感觉有点像我们在使用 Teamware 时陷入了困境，而世界已经转向更新的系统。然而，我并没有错过任何特定的功能，除了可能有一个源树的 Web 视图来浏览和查看文件的历史记录（我们用 VersionTool 做的事情并不重要）。

使用 SUN Teamware 的团队是否应该迁移到更现代的 SCM，例如 git 或 Mercurial？

更重要的是，你可以向团队的其他成员提出什么论据来支持这种转变？

我有一个需要在客户端机器上升级的 .net (2.0) winforms 应用程序。目前，这是通过增加所有项目的程序集版本和文件版本并增加 VS2008 中安装程序项目的版本来完成的。

该应用程序现在利用独立存储将一些用户设置保存在 XML 文件（网格布局等）中。

我现在面临的问题是，如果我增加所有版本号，则应用程序的独立存储有一个新位置，因为文件版本已经改变。有了新的隔离存储位置，所有设置实际上都丢失了。

升级时，Windows 安装程序是否会根据文件版本或程序集版本替换 dll ？

如果它是程序集版本，那么我所要做的就是不增加文件版本。

作为开发人员，我经常对可以使您的生活更轻松的新语言功能感兴趣。例如，Java 5 为该语言带来了泛型和注释，这些特性绝对可以提高您的工作效率。

然而，当我回顾近十年在 java 平台上的工作时，我发现版本控制相关的问题是导致效率低下和不必要的努力的最大罪魁祸首。寻找正确版本的 jar，尝试调和一些版本冲突，升级依赖库等数小时和数小时。当我开始使用 java 时，事情并没有那么困难，你会有一些 3rd 方库，仅此而已. 今天，您的典型 Web 应用程序可能很容易使用：Spring Framework、Hibernate、Struts，应有尽有。所有这些都带有许多相关的第 3 方库。今天，我的耳朵档案通常包括大约 40 个或更多的 3rd 方库。一个真正的罐子地狱！

例如，使用注释，我不必管理 Hibernate 的配置文件。一个不错的功能，但我没有看到由于我将描述符保存在单独的文件中而引起的许多问题。使用泛型，我不必编写强制转换语句，但在我的整个编程载体中，我不记得使用类型安全容器可以防止的单个错误。版本控制问题的解决方案不是更有价值吗？

所有这些问题都导致了许多工具，如Maven、ivy、One Jar、Jar Jar Links（不是在开玩笑！），甚至恰当地命名为Jar Hell等。即使您使用其中一些工具，您也远不能对问题。我使用 Maven 2，它帮助很大。尽管如此，它本身就是一个世界。新手程序员可能需要一段时间来学习它。将遗留项目迁移到 Maven 结构也很痛苦。

似乎在 .Net 中，他们已经吸取了 dll 地狱的教训，并且 .Net 程序集的管理要简单得多。

似乎有计划为 java 平台和 OSGI 等替代品解决这个问题。我认为急需一些基本的和平台强制的版本控制机制

我想知道这一点，因为我刚刚意识到，我以前从未与提供过候选版本的公司打交道，而且我看到这些天越来越多地使用这个词，所以我想更清楚地了解他们影响。

对于以前为提供 RC 的公司实际工作过的任何人……是否有任何更正式的规范来说明候选版本的实际需要（例如 RC 和 Beta 之间的区别），或者它只是一个政策每个公司自己决定的事情？

如果您碰巧在一家拥有此类规范的公司工作，您能否提供一些示例，说明它所阅读的某些指南确实将版本提升为“候选发布版”。