如何避免将本地更改提交到SVN仓库？

Question

我需要在不同的环境下运行项目，因此必须对项目文件进行本地更改。但是，我已经两次意外将这些更改提交，导致其他人的运行环境出现问题。

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

我尝试在同一代码库中设置第二个分支（结果失败了，在代码库的根目录中重复了整个树形结构——我不会再去玩那个了）。

我还尝试建立自己的第二个代码库，并将仅更改过的文件检入新代码库。但这样做非常混乱，基本上没有起到作用。

我正在考虑使用SVK——它看起来可能有所帮助，但我无法找到适合我的模式。

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

我意识到我可以跟踪我想要检查的更改，然后只检查这些更改，但这是一个依赖于人类的错误程序，迄今为止，它已经让我失望两次（因为我是个有缺陷的人）。

你有什么建议吗？

- Bill K

---

我个人有两个代码文件夹：一个是我的代码，另一个与代码库同步。但这需要手动合并才能提交。我想知道是否有更好的方法，所以点赞+1。 - Michael Myers

Answer 1

你使用什么客户端？

TortoiseSVN有一个巧妙的功能，利用了内置于SVN中的changelist功能。如果你右键单击修改过的文件夹并选择“检查修改”，你可以在该对话框中右键单击任何已修改的文件，并选择“添加到更改列表 -> 忽略提交”。从那时起，每当你执行提交操作时，Tortoise会确保不将这些文件添加到提交中。请参见此页面上的“从提交列表中排除项目”。

如果你没有使用tortoise，则可以手动设置类似的更改列表。

- Nick Meyer

---

这似乎是一个不错的解决方案，但我认为变更列表作为父目录元数据的一部分被检入了。这意味着它将被所有人忽略（这将非常糟糕）。我错了吗？变更列表是本地的吗？ - Bill K

“我错了吗，变更列表是本地的吗？” 是的。对于 SVN 而言，它只是一个工具，让你以文件为粒度将本地更改分组。它没有被检入。（我也使用那个“忽略提交”选项，并且正准备提出同样的建议。） - sbi

太好了！这似乎几乎完美——实际上我正在操作，但在我试图不要检查新文件或目录时，它不给我那个选项。还有其他的技巧吗？（我想我可以把它们添加到SVN-IGNORE中，但理论上可能会使客户困惑，因为那是被检入的。） - Bill K

作为对我之前评论中自己问题的（部分）回答，您可以先进行添加操作，然后将该添加操作放入更改列表中。 - Bill K

Answer 2

您可以使用git-svn。这样，您可以获得一个本地repo，其中包含本地历史记录，并有多种机会在对svn repo进行影响之前考虑您的错误。

- bmargulies

---

我希望尽可能减少人类决策过程，同时减少步骤。这似乎与您所说的相反。如果有一种使用git-svn（或svk，它们是否类似？）的模式，我完全可以接受 - 实际上，那几乎就是我的问题 - 如何使用这样的系统来消除人为因素从checkins中。 - Bill K

+1（每日限制，T_T）。我在工作中完成它。另一个可能的解决方案（也可以减少步骤数量）是完全从过程中清除svn。 - P Shved

Git的价值在于你可以得到一个本地分支。你可以随心所欲地进行编辑，而你所做的任何更改都不会提交回原始仓库。 - bmargulies

Answer 3

我通常会安排标准文件可以被单独的文件覆盖，这些文件在SVN检出时被忽略。

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

（当然，显而易见的问题是，当jetty.xml得到更新时，它们不会合并到jetty-local.xml中，但这可能比您已经面临的问题要少。）

在我过去参与的PHP项目中，这一点甚至被进一步扩展为两个独立的代码树 - /system存放所有系统类，/local则是其镜像，但除非添加了本地类，否则为空，此时将优先加载本地类。这可能过于花哨了。

如果你拥有的是配置文件，而这是问题所在，那么我使用的另一种解决方案是按层次结构读取它们（即首先读取global.cfg.default，然后用global.cfg.local中的任何设置进行覆盖）。

- Matt Sheppard

---

我很想做到这一点，但这将涉及对构建过程进行更改。这些人已经太忙了，没有重构来支持我不能记住不要检查配置文件的事实。 - Bill K

Answer 4

当我遇到这种情况时，我会将不想检查的文件添加到一个标记为“不要检查”的变更集中。我的SVN客户端（SmartSVN，尽管Tortoise也支持此功能）可以设置为忽略该变更集，这意味着我不会意外地检入这些更改。

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

- adrianbanks

Answer 5

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

web.deploy.config
web.dev.config

这些都将在源代码控制下。然后将其中一个文件复制到运行它的服务器上的web.config中（将此文件从源代码控制中排除）。对我来说很有效。

- Nick

Answer 6

在提交之前，我总是会检查所有文件的差异，这样我就可以确保没有留下一些调试代码，并且它给了我第二次审查我的更改的机会。

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

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

另一个检查自己的聪明方式是获取仓库的最新副本并尝试构建和运行它 -- 这样你就可以发现是否忘记添加文件或者破坏了一些显而易见的东西。

- Jason Machacek

---

是的，我总是会检查差异。但是我已经提交了这些愚蠢的文件两次了。我只是试图修复流程中明显有问题的部分（也就是我自己）。 - Bill K

Answer 7

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

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

- Pekka

Answer 8

我使用svn switch功能时运气很好，可以保持个性化文件不会覆盖其他人的配置。在正常的trunk/branches/tags布局中，可以在branches中创建一个包含个性化配置文件的文件夹，然后

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

这将导致配置文件的编辑被保存在您的分支中，而不是主干中。您可以获得版本化的配置文件编辑，并且不容易弄乱主干文件。

- blahdiblah