源代码管理和错误修复的最佳实践

时间:2008-10-20 17:34:19

标签: visual-studio svn version-control patch

如果我们需要发布一个不包含已提交的当前开发或其当前版本的任何更改的错误修补程序,应该采取哪些措施来使该过程更安全且开销更低?

我们目前正在一个主要在Visual Studio 2008中开发的小型(3个开发人员)团队中使用Subversion作为我们的源代码控制。我们预计该团队可能会在明年分组给8个开发人员,以及任何以前的版本支持成为更复杂。虽然大多数客户都在当前版本中,但有些客户却落后了。

3 个答案:

答案 0 :(得分:6)

源代码控制可以非常轻松地处理这个问题,并且专为此而设计。

当您达到释放的稳定期时,应该完成分支。重要的是,在完成此操作之前,不要在下一个版本上开始任何工作。

该版本的任何错误修复都应该在该分支中完成。这可以防止即将发布的新代码污染bug修复。完成错误修复后,您可以根据需要将该更改合并到主干和任何其他版本。

不要忘记将错误号放在注释中,因为这样可以更轻松地跟踪提交。

答案 1 :(得分:3)

如何:每个主要版本的分支,根据需要将错误修复应用于分支,并且还应用(或合并)回主干。

答案 2 :(得分:0)

在我工作的地方,我们有几个同时工作的项目。为了避免这个问题,我们有几个源代码变体。例如,第一个版本是Variant 1.0。我们为此版本创建了一个分支,比如Variant 2.0,用于所有未来的开发。如果我们需要修复错误,我们会在主Variant上执行此操作,该版本目前为1.0并且可以释放它。当Variant 2.0准备好投入生产时,我们将它与主分支上的任何内容合并(在本例中为1.1),并成为新的主干线。有一次,我们有4个分支同时运行。

合并代码可能非常耗时,并且在合并期间必须小心不要引入新的错误,但是如果你有一个不错的代码比较工具,那么它应该不会太糟糕。我们在10,000个文件源目录上使用Beyond Compare进行了一段时间的合并,并且只花了一个上午。