我必须对我的项目文件进行本地更改才能使其在不同的环境中运行。两次，我不小心检查了这些更改（并且弄乱了其他人的运行环境）。如何避免检查SVN存储库的本地更改？
可能有很多更好的方法来建立我们的构建，但是因为我作为一个建立项目的顾问工作，我不能真正改变客户的工作方式。
我已经尝试在同一个存储库中建立第二个分支（这会导致在其存储库的根目录中复制整个树 - 我不会再对此进行混淆）。
试图设置我自己的第二个存储库，并只检查这些文件到新的存储库。这真的很混乱，基本上没有工作。
我正在考虑SVK - 它看起来能够帮助，但我不能完全弄清楚一个可行的模式。
我想我甚至在这里发布并没有得到一个很好的答案，但那是在我认真考虑SVK之前 - 我认为这个新参数可能有更好的解决方案。
我意识到我可以跟踪我想要检查的变化，然后只检查那些变化，但这是一个人类依赖和越野车过程，迄今为止，我失败了两次（因为我是一个越野车的人）。
关于如何做到这一点的任何建议？
你使用什么客户端？
TortoiseSVN有一个漂亮的功能，利用SVN中内置的changelist功能。如果右键单击修改的文件夹并选择“检查修改”，则可以右键单击该对话框中的任何修改文件，然后选择“添加到更改列表 - >忽略提交。”。从此，无论何时执行提交，Tortoise都确保不将这些文件添加到提交中。请参阅this page的“从提交列表中排除项目”。
如果您不使用乌龟，可以手动设置类似的更改列表。
这似乎是一个很好的解决方案，但我认为更改列表是作为父目录的元数据的一部分签入的。这意味着每个人都会忽略它（这很糟糕）。我错了，更改列表是本地的吗？ – 2009-11-13 22:56:39
“我错了，更改列表是本地的吗？”是的。借助SVN，它只是一个工具，可以将您的本地更改按文件粒度分组。它没有签入。（我也使用“忽略提交”一个，并且即将提出相同的建议。） – sbi 2009-11-13 23:00:17
太棒了！这看起来几乎完美 - 我正在做它，当我试图不检查新文件或目录时，它不会给我这个选项。还有另一个窍门吗？ （我可以将这些添加到SVN-IGNORE我认为，但理论上，这可能会让客户感到困惑，因为它已签入。） – 2009-11-13 23:05:37
你可以使用git-svn。你会得到一个当地的回购协议，你可以在其中获得当地的历史记录，还有几个机会可以在svn回购之前考虑你的罪行。
我想尽可能地去除人工决策过程，同时减少步骤。这种看起来与你所说的相反。如果有一种模式可以使用git-svn（或svk，它们是不是很相似？），我完全赞同它 - 事实上，这几乎是我的问题 - 如何使用这样的系统来从登录中删除人员元素。 – 2009-11-13 23:01:11
+1（每日限制，T_T）。我在工作中做。另一个可能的解决方案（这也会减少步骤的数量）将完全清除流程中的svn。 – 2009-11-13 23:09:00
git的值是你得到一个本地分支。你可以编辑你心中的内容，并且不做任何事 - 没有任何东西会将这些变化回复到原始回购。 – bmargulies 2009-11-13 23:30:48
我想不出任何简单的方法来做到这一点。是否无法动态检查（在您的文件/脚本中）您所处的环境，并相应地进行设置？我曾经在PHP中用一个简单的目录检查（如果工作目录等于C：\ projects ...然后设置路径...）
另一个选项可能是一个预先提交钩子，它会排除或恢复更改文件，但在前一种情况下，您不会更新，而在后者中，您必须再次进行更改......嗯。
我一般尽量安排事情，所以标准的文件SVN签出可以由被svn的一个单独的文件覆盖：忽略-ED
例如，我有利用其启动Jetty Web服务器bash脚本一个配置文件。通常它是jetty.xml，但是如果jetty-local.xml存在于文件系统中，那就用它了。 （当然，当jetty.xml得到一些更新时，它们不会被合并到jetty-local.xml中，但这可能不像你已经面对的问题那么明显的问题）
在一个我曾经使用过的PHP项目中，我们更进一步使用了两个独立的代码树 -/system，其中所有的系统类都被检出，/ local被镜像，除非是本地班级被添加，在这种情况下，它被优先加载。为了自己的利益，这可能太过幻想了。
如果是您拥有的配置文件是问题，我使用的另一个解决方案是安排分层读取它们（即读入global.cfg.default，然后覆盖global.cfg.local中的任何设置）。
我希望能够做到这一点，但它会涉及到构建的变化。这些人太忙了，没有重构来支持我不记得不检查配置文件的事实。 – 2009-11-13 22:58:13
当我遇到类似情况时，我将不想签入的文件添加到标签为“请勿签入”的更改集中。我的SVN客户端（SmartSVN，虽然乌龟也赞同这一点）可以设置为忽略该变更集，这意味着我不会意外检查这些变化。
的唯一的缺点是当你已经更改的变更集文件，你真的想检查 - 你就必须手动记得要检查他们
我有好。使用svn switch来保护个性化文件免于跺脚他人的配置。给定一个正常的中继/分支/标签布局，让自己在包含您的个性化配置文件的分支中的文件夹。然后
svn switch URL-to-personalized-config URL-to-standard-config
这将导致配置文件的编辑保存在您的分支而不是中继。你可以对你的配置文件进行版本编辑，并且不能轻易搞乱中继文件。
解决方案取决于您正在讨论的更改数量。我与.net网站合作，所以对于大多数网站我都会为每个环境配置不同的配置文件。例如：
web.deploy.config
web.dev.config
这些都将在源代码控制之下。然后将这些文件中的一个复制到正在运行的服务器上的web.config（将此文件从源代码管理中删除）。适用于我。
我总是在提交之前查看所有文件的差异，这样我就可以确保不会留下一些调试代码，并且使我有机会再次查看我的更改。
如果你在Unix/Linux机器上运行tksvn安装w ^/tkdiff，您可以通过一个该用这个命令检查了每一个DIFF一个不错的图形表示：
for FILE in `svn status | grep -v ? | sed -n "s/^[MA]//p"`; do tkdiff $FILE; done
另一个智能重新检查自己的方法是检查一个新的版本库，并尝试构建并运行它 - 这样，如果您忘记添加文件或破坏某些显而易见的内容，就可以捕获该文件。
是的，我总是检查差异。但我已经检查了这些愚蠢的文件TWICE。我只是想解决这个过程中显然已经破裂的部分（我） – 2009-11-13 23:22:04
我个人有两个代码文件夹：一个代码和一个与存储库同步的代码。但是这需要在提交之前进行手动合并。我想知道是否有更好的方法，所以+1。 – 2009-11-13 22:48:53