Question

我之前发过一个问题Moving away from VSS，其中我询问了使用VSS的Delphi开发人员的最佳VCS控制。大多数开发人员似乎都使用带有TortoiseSVN的svn。我试了好几天，我觉得这是最好的选择。

但是，我仍然对svn的工作方式感到困惑，所以这里有一些我想回答的问题：

我可以使用vss使用的旧锁定方式（checkout-modify-checkin）吗？
Delphi表单有两个文件（MyForm.pas，MyForm.dfm）。当我向表单添加任何控件时，两个文件都将被修改，所以我想提交“myform.pas”并让“myform.dfm”也提交它。我在这里遗漏了什么吗？
这同样适用于Delphi项目文件。因为这与其他文件链接，所以当我更改项目文件时应该提交所有文件。
您在TSVN中标记了哪些文件被忽略，因此TSVN不会查找这些文件，如（ .dcu， .exe，...），我可以导出吗？它从一个PC到另一个？

我现在必须改变我在vss风格中思考的方式，并且需要将其更改为SVN样式，但是使用vss，所有内容都在IDE中管理，这非常棒; - ）。

更新

5.如果我提交Delphi表单（.pas＆amp; dfm）并发现之前已经更新了某个版本，如果在该表单和单元中添加了一些新的控件和事件，那么如何解决冲突（这需要Delphi开发人员使用svn）。

Answer 1

是的，您仍然可以锁定文件，但不建议这样做。您必须在可能要锁定的所有文件上设置svn：needs-lock属性，以便在签出时获取readonly标志。但同样，这不是文本文件的推荐工作流程。只需尝试修改合并工作流程即可！
由于您使用的是TortoiseSVN：右键单击您的父文件夹，选择“提交”。在提交对话框中，您将看到需要提交的所有文件。只需检查myform.pas和myform.dfm文件即可。所有已检查的文件将一起提交，不需要（绝对不推荐！）单独提交每个文件！
参见2. - 但你应该首先阅读精彩的Subversion book来熟悉这个概念。您应该始终提交属于逻辑更改的所有文件。例如，如果向表单添加新控件并实现代码来处理它，那么您可能不仅仅修改了表单文件，还修改了多个文件。始终将所有这些文件提交到一起，因为提交是一个逻辑实体。
您不必“导出”忽略设置。只需添加svn：ignored属性即可。使用TortoiseSVN非常容易，如docs中所述。

Answer 2

回复5：你应该尝试一下。为了限制冲突的可能性，主动开发人员经常提交，并且所有其他人经常从SVN更新，这是一个非常好的主意。设置电子邮件提交通知可以提供很多帮助，以便所有人都知道何时更新。但话说回来 - 您会发现删除控件及其所有事件处理程序，添加控件和一些处理程序的简单操作不会导致您需要手动解决的冲突。

编辑： This answer by DiGi表示即使用户没有，Delphi也会修改DFM。这不是真正的IMO，因为DFM时间戳的简单更改不符合DFM文件的本地修改，SVN也不会提交新版本。但是要注意不要在Delphi IDE中移动表单，因为这会改变表单的Top和/或Left属性。同样，更改页面控件的活动页面将被视为本地修改。因此，在提交之前检查所有本地修改是一个好主意，并将所有那些只是意外修改。

编辑2：正如onnodb在他的评论中指出的那样，似乎确实有自动修改的表单属性，至少在Delphi 2007中（可能稍后会有？）。这将强调在提交之前检查所有本地修改的重要性。

Answer 3

另请参阅How do I start with working Sub-Version + Delphi?了解一些也集成到Delphi IDE中的SVN工具。

Answer 4

是。
TortoiseSVN会在您提交时自动标记版本控制下的所有已修改文件。
见2.
创建忽略列表非常容易。只需右键单击一个文件，您就可以选择忽略该文件类型的所有文件。

如果您使用的是Visual Studio，则可以使用Ankh SVN进行IDE集成。

Answer 5

开发人员可以使用CommitMonitor来接收有关新提交的信息。

ad 5：如果两个或更多开发人员使用相同的.dfm，则会很糟糕。简单的修改可以很好地工作（合并）。只有当你真正在文件中有所不同时才重要。 Delphi通常会修改.dfm，即使你没有改变任何东西。

Answer 6

我通常在从SVN更新之前使用这个小python脚本，以便清理我的源代码树。

我将.dof文件存储在SVN中，因此我需要在清理源树之前手动提交任何.dof更改。

import os
import sys

exts = ['.~pas', '.~dpk', '.~bpl','.dcu', '.~dcu', '.dcp', '.~dcp',
        '.dof', '.cfg', '.res', '.~res']

def mydir():
    if __name__ == '__main__':
        filename = sys.argv[0]
    else:
        filename = __file__
    return os.path.abspath(os.path.dirname(filename))


def clean_dir(arg, dirname, names):
    for name in names:
      if os.path.splitext(name)[1].lower() in exts:
        file2delete = os.path.join(dirname,name)
        print os.path.join(file2delete)
        os.remove(file2delete)


if __name__=="__main__":
  print "Cleaning Tree"
  os.path.walk(mydir(), clean_dir, "a")

Answer 7

对我来说，DFM文件本身不会改变。

我不确定其他人对他们的dfm文件做了什么，或者Delphi中的哪些设置可能会导致这种情况。我没有问题。在“提交”对话框中仅列出（更改的）我更改的dfm文件。我正在使用Delphi 2007和Delphi 7。

Answer 8

以下是我们对DFM文件行为的看法： *无论有问题的Delphi版本如何，IDE都会提示devoloper“保存”一个表单，即使PAS级别的DFM级别没有发生真正的更改。示例：开发人员在IDE中稍微重新定位了formX的设计窗口，但对formX没有任何其他操作。在VSS下，文件的只读属性充当了警察 - 确保没有“不变更改”成为签到的候选人。 *根据我们的经验，对于坐在WinVista或Win7盒子上的开发人员而言，在D2006下，以及可能在诸如D2007和D2009之类的堂兄IDE中，情况正在恶化。在设计模式下，表单的某些操作将“移动”底层DFM中的像素值。并且移动开发人员可能不会注意到的足够小的值（2,6）。面板和滚动框似乎特别脆弱。所有这些在VSS期间，没有开发人员的意图，这是一个小麻烦，因为只有明确检出的DFM才有“转移”的风险。在SVN / Tortoise下，这个问题越来越多，因为没有只读保护文件。是的，是的，最终，develper负责在登记时间仔细检查DFM作为文本级别的变化。但这是一个麻烦，增加了开发周期的开销，我们当然希望不是这样。有趣的是，WinXP工作站不会发生这种“转变”。为什么这么重要，对于SVN / Tortoise社区。无论出于何种原因，任何人都匆忙地检查DFM可能会让“转变”接管有效的UI命令。并使一个人对蛮力VSS只读属性感到怀旧;甚至考虑使用上面提到的svn：needs-lock属性。小姐我有一些提议的解决方案，但到目前为止我们发现自己只有变量，并且是游戏规划如何通过我们的SVN / Tortoise实现来最小化DFM问题。仅供参考，我们目前看不到Embarcedero发布的“转变”症状。

Answer 9

你们可以SourceConexion。它集成在Delphi IDE中。它支持锁定文件，因此您不会遇到DFM文件的问题。

我在使用C＃时使用TortoiseSVN但是在Delpi中我觉得使用SC是好事，因为在多个开发人员对其进行了更改后我最终得到了损坏的DFM文件。

适用于Delphi开发人员的SVN

9 个答案: