8

我是来自 Visual Source Safe (VSS) 背景的 Subversion (SVN) 新手。在 VSS 中，编辑文件的人会检出该文件，并阻止其他用户通过 Visual Studio 对其进行编辑。我知道 SVN 是一种并发模型，允许多人处理同一个文件，然后将更改合并在一起。我的问题是这样的：

  1. 避免让用户编辑同一个文件（编写大量代码）并面临复杂的更改合并或更糟糕的是编写大量代码却发现文件被另一个用户锁定的最佳方法是什么？

  2. 有没有办法在检索文件时通知用户它当前正在被另一个用户编辑或当前被另一个用户锁定？

其他详情：

使用 VisualSVN 服务器作为 SVN 服务器。
使用 TortoiseSVN 和 AnkhSVN 客户端。

4

11 回答 11

12

我也是前 Visual Source Safe 用户。合并曾经让我发疯，直到我意识到这不是技术问题，而是人员问题。在使用 VSS 时，大多数开发人员会在必须签入代码之前尝试尽可能多地完成工作。这种行为是导致复杂合并的原因。

以下是一些可以缓解这种情况的事情：

  • 在开始之前始终更新您的工作副本
  • 经常入住。这将使代码更改更小，更容易自动合并
  • 不要让工作代码处于未选中状态
  • 如果更改需要几天或更长时间，开发人员应该创建自己的分支

这些东西帮助很大，尤其是当我工作的团队越来越大的时候。从 VSS 复制锁定行为是一个非常糟糕的主意，并且会导致更多问题。只需拥抱新的工作流程。

如果您仍然想使用某个工具，那么我建议您查看SVNMonitor。

于 2009-11-12T14:46:27.567 回答
8

我想建议采用不同的方法来使用颠覆。

  • 您应该经常获得更新。
  • 您还应该尽早并经常入住。

使用这种方法，合并通常很少发生并且会自动发生。在发生冲突的情况下，这些通常较小。

于 2009-11-12T14:37:59.957 回答
3

我在之前从基于锁的系统转到 SVN 的地方遇到的几点。

尝试在 SVN 中复制锁定-编辑-解锁行为并不是一个好主意，因为它的设计方式是您不需要以这种方式工作。SVN 使用的合并算法非常好，我只遇到过少数需要在合并期间进行手动干预的情况。在同一个文件上工作的两个人实际上会接触同一行是非常罕见的，而后者通常是唯一需要手动干预的时候。

SVN 真正设计用于经常从主干或当前分支更新的环境。如果您必须进行长期工作或更改文件中的大量代码的工作，则最好使用分支来完成工作并将其重新合并。是的，您必须进行一些合并时不时会感到疼痛，但它比使用非设计为以这种方式工作的系统所获得的疼痛要少得多。

如果您尝试将 SVN 用作“本机 SVN”而不是用作具有不同名称的 VSS，那将是痛苦的，而且不值得麻烦。适应新的范例，您会惊讶地发现，与旧的“在任何给定时间只有一个用户编辑给定文件”例程相比，以这种方式工作要好得多。

于 2009-11-12T14:43:37.763 回答
2

您可能希望使用旧 VSS 样式锁定模型的唯一时间是您想要版本的二进制文件（MS-Word 文档等），但 SVN 无法自动合并来自多个源的更改。

于 2009-11-12T15:56:37.897 回答
2

首先，如果可能的话，避免在不签入文件的情况下编写“大量代码”可能是明智之举。如果你有一个好的单元测试套件（如果没有，为什么不呢？:)，那么只要你在绿条上签到，频繁提交是最好的。

然后，如果您确实有必要进行需要很长时间的更改，则值得svn update定期进行一次以尽可能与主干保持同步。Subversion 在合并方面相当可观（与 VSS 相比），并且可以很好地处理大部分内容。

任何它无法处理的东西，都会进入冲突状态，让您使用您选择的合并工具来解决冲突（我推荐WinMerge，它是王牌）。

于 2009-11-12T14:39:21.423 回答
1

我会花一些时间学习“签到舞”

这是一角钱。

网上也有多篇关于此以及如何减轻痛苦的文章。

于 2009-11-12T14:36:51.080 回答
1

虽然 SVN 有一个lock命令，但最常见的 SVN 使用方法是乐观的锁定方法。

这意味着您和我可以编辑同一个文件而不必太担心（大多数时候我们不会，因为我们将处理项目的不同部分）。如果我首先提交对文件的更改，那么您的提交尝试将失败。这时候 SVN 会通知你。

然后，您必须运行“更新”命令，这将（很可能）自动将我提交的更改与您的本地更改合并，然后您的下一次提交尝试将通过。

为了避免这种乐观方法遇到麻烦：正如其他人所建议的那样，经常提交，不要一次提交太多！

于 2009-11-12T15:46:38.947 回答
1

不是问题。使用 Tortoise SVN，执行此操作...

  1. 在 Windows 资源管理器中，右键单击文件。
  2. 选择“Tortoise SVN”，然后选择“获取锁定...”
  3. 在“锁定文件”对话框中，填写锁定原因。
  4. 单击确定。
于 2009-11-12T14:40:29.983 回答
1

SVN 是一种并发模型，允许多人处理同一个文件，然后将更改合并在一起。

我认为这更多的是在由一堆或多或少的独立文件组成的同一个项目上工作。处理同一个文件并合并结果当然是可能的，并且时不时发生，但这绝对不是默认/所需的操作模式。所以：

  • 经常更新。
  • 经常提交。
  • 避免使用大的类/文件（1000 行太多了）。这也有额外的好处:-)
于 2009-11-12T14:41:28.920 回答
0

简短的回答：

  1. 经常更新。早点入住，经常入住。如果您的工作时间更长（超过一两天），请考虑创建一个功能分支。
  2. 不。

有点长的答案：

如果多个开发人员对同一个文件进行“大量更改”，那么无论是您的开发人员的工作方式还是功能分布在不同文件中的方式都有问题。我一直在不同规模的团队中使用 CVS 和 SVN，而 IME 很少有合并成为真正问题的情况。（这些通常是基本服务的更改，如字符串、日志记录、错误处理等，需要更改几乎所有代码。这种情况需要一些人工交互和计划才能顺利进行。）

于 2009-11-12T14:49:43.177 回答
0

我同意其他所有人的看法，尽可能早且经常地入住（并非总是可行）。如果你正在做一些复杂和新的事情，它可以在一个分支上完成——同样的规则也适用，尽早并经常提交，并在哪里让你的分支尽可能保持最新，并使用头部的代码。

根据我们的经验，大多数人往往不会同时处理同一个文件或至少文件的同一部分（在 VSS 中你不能，所以你的工作模式可能已经支持你了）。

另一件关键的事情 - 确保每个人都使用相同的规则来使用制表符/间距、布局和格式化，无论如何这是一个很好的做法，但你越一致，你就越不可能找到代码之间的“差异”不存在的文件。

此外，我建议您查看持续集成，即拥有一个构建服务器，这在确信您提交的代码将在“干净”环境中构建的信心方面提供了相当大的好处，并且如果您配备了适当的测试，将为您提供进一步相信它仍然有效 - 即使在复杂的合并过程之后。

我们使用我们认为非常出色的TeamCity - 但还有其他的。

于 2009-11-12T15:04:30.760 回答