SVN-如何在预提交时拦截、更改或添加文件？

首先，我不确定这是否可能，但我需要知道如何才能做到，如果不能，为什么不能

我想创建一个C#应用程序，在subversion存储库（我相信是预提交）提交过程中的适当时间运行，然后再添加另一个要提交的文件

例如，我对Program.cs和Main.cs进行了更改，但未对AssemblyInfo.cs进行更改。我希望能够强制更改AssemblyInfo.cs或任何相关文件

我使用SharpSVN编写了一个控制台应用程序，它在提交后启动，然后替换了一个文件，但这导致版本号增加。显然这并不理想

然后，我在SharpSVN中找到了SvnLookClient，它在预提交时运行，并已开始编写一些内容，但当我意识到CopyFromPath并不是我所期望的那样时，它就陷入了死胡同：

    using (SvnLookClient client = new SvnLookClient())
    {
        SvnLookOrigin o = new SvnLookOrigin(@"\\server\repository");
        SvnChangedArgs changedArgs = new SvnChangedArgs();
        Collection<SvnChangedEventArgs> changeList;
        client.GetChanged(o, changedArgs, out changeList);
    }

使用（SvnLookClient=new SvnLookClient（））
{
svnlookogin=新的svnlookogin（@“\\server\repository”）；
SvnChangedArgs changedArgs=新SvnChangedArgs（）；
收集更改列表；
client.getchange（o、changedArgs、out changeList）；
}

---

或者，我会满足于在C#之外执行此操作，但理想情况下，我希望在C#控制台应用程序中执行此操作，这样我还可以告诉我的存储库服务器执行其他任务，如在数据库脚本中运行等。

在钩子脚本期间，您不能修改事务。您可以使用消息（）拒绝提交，也可以在提交后的单独提交中进行

[编辑] 我想澄清为什么修改事务是个坏主意（从技术上讲是svn）：

客户对此一无所知。

除了“OK”、“FAILED”和stderr输出之外，在提交期间没有从服务器到客户端的反向通道

当客户端提交其更改并且报告提交成功时，它会将其本地文件和文件夹状态标记为与存储库版本[xyz]同步。当您稍后更改某些内容时，例如，在本地添加文件，它希望提交这些更改，但是。。。好吧，你们可以试着知道会发生什么，我希望“校验和错误”或“文件已经添加”会出现一些情况。根据更改的类型，您可能没有比删除文件夹并重新签出损坏的零件更好的机会获得工作WC

这是技术部分。现在，开发人员方面：首先，自动正确地修复更改似乎很明智，但它将失败，因为一个简单的事实是，如果源代码是可预计算的，我们就不必让开发人员编写它。您希望您的开发人员做正确的事情

这一点最好通过教育来实现：他们必须知道什么是正确的事情。让他们知道一些事情的好方法是，除了良好的旧培训之外，给他们反馈

来自svn服务器的错误消息、断开的构建或单元测试后的自动邮件、静态源代码分析工具的结果等，也可以作为良好的教育工具

我建议使用持续集成，并在那里验证源代码树。这样做的好处是，开发人员在长时间工作后不会被阻止提交其更改，但您仍然知道源代码树的状态

现在，我猜您想要实现什么：服务器端源代码树应该始终是“功能性的”。然后问题是，即使使用自动文件修复、预提交单元测试、样式检查等等，您最终还是必须通过旧式的系统测试来检查程序是否实际工作。所以基本上，你并没有得到任何东西

技术可以支持流程，经过深思熟虑的工具可以很好地支持流程，因此遵循流程实际上可以帮助开发人员节省时间并简化工作流程。但技术通常无法取代流程，也无法取代人类智能（至少目前如此）。

---

[/edit]

在钩子脚本期间，不能修改事务。您可以使用消息（）拒绝提交，也可以在提交后的单独提交中进行

[编辑] 我想澄清为什么修改事务是个坏主意（从技术上讲是svn）：

客户对此一无所知。

除了“OK”、“FAILED”和stderr输出之外，在提交期间没有从服务器到客户端的反向通道

当客户端提交其更改并且报告提交成功时，它会将其本地文件和文件夹状态标记为与存储库版本[xyz]同步。当您稍后更改某些内容时，例如，在本地添加文件，它希望提交这些更改，但是。。。好吧，你们可以试着知道会发生什么，我希望“校验和错误”或“文件已经添加”会出现一些情况。根据更改的类型，您可能没有比删除文件夹并重新签出损坏的零件更好的机会获得工作WC

这是技术部分。现在，开发人员方面：首先，自动正确地修复更改似乎很明智，但它将失败，因为一个简单的事实是，如果源代码是可预计算的，我们就不必让开发人员编写它。您希望您的开发人员做正确的事情

这一点最好通过教育来实现：他们必须知道什么是正确的事情。让他们知道一些事情的好方法是，除了良好的旧培训之外，给他们反馈

来自svn服务器的错误消息、断开的构建或单元测试后的自动邮件、静态源代码分析工具的结果等，也可以作为良好的教育工具

我建议使用持续集成，并在那里验证源代码树。这样做的好处是开发人员不必担心