如何避免将本地更改签入 SVN 存储库？
我必须对项目文件进行本地更改才能使其在不同的环境中运行。现在我两次不小心检查了这些更改（并弄乱了其他人的运行环境）。
可能有很多更好的方法来设置我们的构建，但由于我是一个已建立项目的顾问，所以我无法真正改变客户的工作方式。
我尝试在同一个存储库中设置第二个分支（这适得其反，将整个树复制到其存储库的根目录中——我不会再搞乱了）。
尝试设置我自己的第二个存储库并将这些文件签入新存储库。这也变得非常混乱并且基本上不起作用。
我正在考虑 SVK——看起来它可能会有所帮助，但我不太能找出一种可行的模式。
我想我什至在这里发帖并没有得到一个好的答案，但那是在我认真考虑 SVK 之前——我认为有了这个新参数可能会有更好的解决方案。
我意识到我可以跟踪我想要签入的更改，然后只需签入这些更改，但这是一个依赖于人类且有缺陷的过程，迄今为止，它已经让我失败了两次（因为我是一个有缺陷的人）。
关于如何做到这一点有什么建议吗？
I have to make local changes to my project files in order to get it to run in a different environment. Twice now I accidentally checked those changes in (and messed up everyone else's running environment).
There are probably a lot of better ways to set up our build, but since I work as a consultant on an established project I can't really change how the customer works.
I've tried setting up a second branch in the same repository (which backfired, duplicating the entire tree in the root of their repository--I won't be messing around with that again).
Tried setting up a second repository of my own and checking in JUST those files to the new repository. This got really messy as well and basically didn't work.
I'm considering SVK--it looks like it MIGHT be able to help, but I can't quite figure out a pattern that would work.
I think I even posted here and didn't get a good answer, but that was before I was seriously considering SVK--I figured with that new parameter there might be a better solution.
I realize I could track the changes I WANT to check in and then just check those in, but that's a human dependent and buggy procedure that, to date, has failed me twice (because I'm a buggy human).
Any suggestions on just how to do this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
你用什么客户端？
TortoiseSVN 有一个巧妙的功能，可以利用 变更列表 SVN 内置功能。如果右键单击已修改的文件夹并选择“检查修改”，则可以右键单击该对话框中的任何已修改的文件，然后选择“添加到更改列表 -> 提交时忽略”。从那时起，每当您执行提交时，Tortoise 都会确保不将这些文件添加到提交中。请参阅此页面上的“从提交列表中排除项目” 。
如果您不使用 tortoise，您可以手动设置类似的更改列表。
What client do you use?
TortoiseSVN has a nifty feature that takes advantage of the changelist feature built into SVN. If you right click on a modified folder and choose "Check for Modifications," you can right-click on any of the modified files in that dialog and choose "Add to Changelist -> ignore-on-commit." From then on, whenever you perform a commit Tortoise makes sure not to add those files to the commit. See "Excluding Items from the Commit List" on this page.
If you're not using tortoise, you could set up a similar changelist manually.
你可以使用 git-svn。您将获得一个本地存储库，您可以在其中了解本地历史记录，并且在将其施加到 svn 存储库之前有几次机会考虑您的错误。
You could use git-svn. You get a local repo in which you can have local history, and several opportunities to consider your sins before inflicting them on the svn repo.
我通常会尝试安排一些事情，以便 SVN 检出的标准文件可以被 svn:ignore-ed 的单独文件覆盖。
例如，我有一个 bash 脚本，它使用配置文件启动 Jetty Web 服务器。通常它是 jetty.xml，但如果文件系统上存在 jetty-local.xml，则使用它。
（当然，明显的问题是，当 jetty.xml 获得一些更新时，它们不会合并到 jetty-local.xml 中，但这可能比您已经面临的问题要小。
）我曾经参与过的 PHP 项目，这是通过两个单独的代码树进一步实现的 - /system，其中所有系统类都被签出，而 /local 镜像它，但除非添加本地类，否则是空的，在这种情况下它是优先加载的。这很可能过于花哨，不利于其自身的利益。
如果问题出在您拥有的配置文件上，我使用的另一个解决方案是安排分层读取它们（即读取 global.cfg.default，然后用 global.cfg.local 中的任何设置覆盖）。
I generally try to arrange things so the standard files SVN checks out can be overridden by a separate file which is svn:ignore-ed
For example, I have a bash script which starts a Jetty web server using a config file. Normally it is jetty.xml, but if jetty-local.xml is present on the filesystem, that's used instead.
(Of course, the obvious problem there is that when jetty.xml gets some updates, they won't be merged into jetty-local.xml, but that may be less of a problem than what you're already facing.)
In a PHP project I used to work on, this was taken even further with two separate code trees - /system where all the system classes were checked out, and /local which mirrored it, but was empty unless a local class were added, in which case it was loaded in preference. That may well be getting too fancy for its own good.
If it's configuration files which you own that are the problem, another solution I've used is to arrange to read them hierarchically (i.e. read in global.cfg.default, then overwrite with any settings in global.cfg.local).
当我遇到这样的情况时，我将不想检入的文件添加到标记为“请勿检入”的更改集中。然后，我的 SVN 客户端（SmartSVN，尽管 Tortoise 也支持这一点）可以设置为忽略该更改集，这意味着我不会意外地签入这些更改。
这样做的唯一缺点是，当您对更改集中的文件进行了更改并且确实想要签入时，您必须手动记住将它们签入。
When I have a situation like this, I add the files that I do not want to check in to a change set labelled "DO NOT CHECK IN". My SVN client (SmartSVN, although Tortoise does also suuprt this) can then be set to ignore that change set, meaning that I don't accidentally check in those changes.
The only downside to this is when you have made changes to files in the change set that you do actually want to check in - you then have to manually remember to check them in.
我想不出任何简单的方法来做到这一点。是否没有办法动态检查（在文件/脚本中）您所处的环境，并进行相应的设置？我曾经在 PHP 中通过简单的目录检查来做到这一点（如果工作目录等于 C:\projects... 则将路径设置为...）
另一个选项可能是预提交挂钩，它排除或恢复更改的文件，但在在前一种情况下，您不会是最新的，而在后一种情况下，您必须再次进行更改......嗯。
I can't think of any uncomplicated way to do this. Is there no way to dynamically check (within your files/scripts) which environment you are in, and make the settings accordingly? I used to do that in PHP with a simple directory check (if working directory equals C:\projects... then set path to ... )
Another option could be a pre-commit hook that excludes or reverts the changed files but in the former case, you would not be up to date, and in the latter, you'd have to make the changes again... hmmm.
我很幸运地使用 svn switch 来防止个性化文件破坏其他人的配置。给定正常的主干/分支/标签布局，在分支中创建一个包含个性化配置文件的文件夹。然后
这将导致对配置文件的编辑保存在您的分支中，而不是保存到主干中。您可以对配置文件进行版本化编辑，并且不会轻易弄乱主干文件。
I've had good luck using
svn switchto keep personalized files from stomping on others' configurations. Given a normal trunk/branches/tags layout, make yourself a folder in branches containing your personalized configuration file. ThenThis will cause edits to the config file to be saved off in your branch and not to the trunk. You get versioned edits to your config file, and can't easily mess up the trunk file.
解决方案取决于您所讨论的更改数量。我使用 .net 网站，因此对于大多数网站，每个环境都有不同的配置文件。例如：
这些都将受到源代码控制。然后将这些文件之一复制到运行该文件的服务器上的 web.config（使该文件不受源代码控制）。对我有用。
Solution depends on how many changes you're talking about. I work with .net websites so for most sites I'd have a different config file for each environment. e.g:
These would all be under source control. Then copy the one of these files to web.config on the server it's running on (leaving this file out of source control). Works for me.
我总是在提交之前检查所有文件的差异，这样我可以确保我没有留下一些调试代码，并且它给了我第二次机会检查我的更改。
如果您在安装了 tksvn w/ tkdiff 的 Unix/Linux 机器上运行，您可以使用以下命令逐个查看每个差异的良好图形表示：
另一种仔细检查自己的聪明方法是查看存储库的新副本并尝试构建并运行它——这样，如果您忘记添加文件或破坏了一些明显的内容，您就可以发现。
I always review the diffs of all my files before a commit, that way I can make sure I'm not leaving some debug code in and it gives me a second chance to review my changes.
If you're running on a Unix/Linux machine with tksvn w/ tkdiff installed, you can check out a nice graphical representation of each diff one by one this with this command:
Another smart way to double-check yourself is to check out a fresh copy of the repository and try to build and run it--that way you can catch if you forgot to add a file or broke something obvious.