如何避免签入对 SVN 存储库的本地更改？答案

【问题标题】：How do I avoid checking in local changes to the SVN repository?如何避免签入对 SVN 存储库的本地更改？
【发布时间】：2018-05-10 08:17:59
【问题描述】：

我必须对我的项目文件进行本地更改，以使其在不同的环境中运行。现在有两次我不小心检查了这些更改（并弄乱了其他所有人的运行环境）。

可能有很多更好的方法来设置我们的构建，但由于我是一个已建立项目的顾问，我无法真正改变客户的工作方式。

我尝试在同一个存储库中设置第二个分支（结果适得其反，将整个树复制到其存储库的根目录中——我不会再搞砸了）。

尝试设置我自己的第二个存储库并将这些文件签入新存储库。这也变得非常混乱，基本上没有用。

我正在考虑使用 SVK——看起来它可能会有所帮助，但我无法完全确定一种可行的模式。

我想我什至在这里发帖并没有得到一个好的答案，但那是在我认真考虑 SVK 之前——我认为使用这个新参数可能会有更好的解决方案。

我意识到我可以跟踪我想要签入的更改，然后只签入这些更改，但这是一个依赖人类且有缺陷的过程，迄今为止，我已经失败了两次（因为我是一个有缺陷的人）。

关于如何做到这一点的任何建议？

【问题讨论】：

我个人有两个代码文件夹：一个包含我的代码，一个与存储库同步。但这需要在提交之前进行手动合并。我想知道是否有更好的方法，所以+1。

标签： svn svk

【解决方案1】：

你用什么客户端？

TortoiseSVN 有一个很好的功能，它利用了 SVN 内置的changelist 功能。如果您右键单击修改过的文件夹并选择“检查修改”，您可以右键单击该对话框中的任何修改过的文件并选择“添加到更改列表 -> 提交时忽略”。从那时起，每当您执行提交时，Tortoise 都会确保不要将这些文件添加到提交中。请参阅this page 上的“从提交列表中排除项目”。

如果你不使用乌龟，你可以手动设置一个类似的更改列表。

【讨论】：

这似乎是一个很好的解决方案，但我认为更改列表已作为父目录元数据的一部分签入。这意味着每个人都会忽略它（这将是非常糟糕的）。我错了，更改列表是本地的吗？
“我错了，变更列表是本地的吗？”是的。使用 SVN，它只是您将本地更改分组到具有文件粒度的类别的工具。它没有签入。（我也使用了“ignore-on-commit”，并且正准备提出相同的建议。）
那太好了！这似乎几乎完美——我实际上正在这样做，当我试图不让它签入新文件或目录时，它并没有给我这个选项。还有什么技巧吗？（我认为我可以将这些添加到 SVN-IGNORE 中，但理论上这可能会使客户感到困惑，因为它已签入。）
作为对上一条评论中我自己的问题的（部分）回复，您可以先添加，然后将添加放入更改列表中。

【解决方案2】：

你可以使用 git-svn。您将获得一个本地存储库，您可以在其中了解本地历史，并有几个机会在将您的罪孽施加到 svn 存储库之前考虑您的罪过。

【讨论】：

我想尽可能减少人工决策过程，同时减少步骤。这种情况似乎与您所说的相反。如果有使用 git-svn（或 svk，它们不相似吗？）的模式，我会完全支持它 - 事实上，这几乎是我的问题 - 如何使用这样的系统来从签到中删除人为因素。
+1（每日限制，T_T）。我在工作中这样做。另一种可能的解决方案（这也将减少步骤数）是彻底清除进程中的 svn。
git的价值是你得到一个本地分支。您可以随心所欲地进行编辑，而您所做的任何事情 - 都不会将这些更改提交回原始存储库。

【解决方案3】：

我通常会尝试安排一些事情，以便 SVN 检出的标准文件可以被一个单独的文件覆盖，即 svn:ignore-ed

例如，我有一个使用配置文件启动 Jetty Web 服务器的 bash 脚本。通常它是 jetty.xml，但如果文件系统上存在 jetty-local.xml，则使用它。

（当然，明显的问题是当 jetty.xml 获得一些更新时，它们不会合并到 jetty-local.xml 中，但这可能比您已经面临的问题要小。 )

在我曾经从事的一个 PHP 项目中，这通过两个单独的代码树进行了更进一步 - /system 检出所有系统类，/local 镜像它，但除非本地类是空的，否则它是空的添加，在这种情况下，它被优先加载。这很可能太花哨了。

如果问题是您拥有的配置文件，我使用的另一个解决方案是安排分层读取它们（即读取 global.cfg.default，然后用 global.cfg.local 中的任何设置覆盖） .

【讨论】：

我很想能够做到这一点，但这会涉及到构建的变化。这些人太忙了，没有重构来支持我不记得不要签入配置文件的事实。

【解决方案4】：

当我遇到这种情况时，我会将不想签入的文件添加到标记为“请勿签入”的更改集中。然后可以将我的 SVN 客户端（SmartSVN，虽然 Tortoise 也支持这个）设置为忽略该更改集，这意味着我不会意外签入这些更改。

唯一的缺点是当您对更改集中的文件进行了您确实想要签入的更改时 - 您必须手动记住签入它们。

【讨论】：

【解决方案5】：

我想不出任何简单的方法来做到这一点。有没有办法动态检查（在您的文件/脚本中）您所处的环境，并相应地进行设置？我曾经在 PHP 中通过简单的目录检查来做到这一点（如果工作目录等于 C:\projects... 然后将路径设置为 ...）

另一个选项可能是排除或还原更改的文件的预提交挂钩，但在前一种情况下，您不会是最新的，而在后一种情况下，您必须再次进行更改...嗯。

【讨论】：

【解决方案6】：

我很幸运使用svn switch 来防止个性化文件影响他人的配置。给定一个正常的主干/分支/标签布局，在分支中创建一个文件夹，其中包含您的个性化配置文件。那么

svn switch URL-to-personalized-config URL-to-standard-config

这将导致对配置文件的编辑保存在您的分支中而不是主干中。您可以对配置文件进行版本化编辑，并且不会轻易弄乱主干文件。

【讨论】：

【解决方案7】：

解决方案取决于您谈论的更改数量。我使用 .net 网站，因此对于大多数网站，每个环境都有不同的配置文件。例如：

web.deploy.config
web.dev.config

这些都将受到源代码控制。然后将其中一个文件复制到运行它的服务器上的 web.config 中（将此文件排除在源代码管理之外）。对我有用。

【讨论】：

【解决方案8】：

我总是在提交之前检查所有文件的差异，这样我可以确保我不会留下一些调试代码，这让我有第二次机会来检查我的更改。

如果您在安装了 tksvn w/tkdiff 的 Unix/Linux 机器上运行，您可以使用以下命令逐一查看每个差异的漂亮图形表示：

for FILE in `svn status | grep -v ? | sed -n "s/^[MA]//p"`; do tkdiff $FILE; done

另一种仔细检查自己的聪明方法是检查存储库的新副本并尝试构建和运行它 - 这样您就可以在忘记添加文件或破坏明显的东西时发现。

【讨论】：

是的，我也经常查看差异。然而，我已经两次检查了这些愚蠢的文件。我只是想修复过程中明显损坏的部分（我）