TortoiseSVN / TortoiseMerge 中出现神秘的不变

发布于 2024-08-09 00:03:35 字数 1059 浏览 3 评论 0原文

我使用 TortoiseSVN 进行版本控制。在我已经工作了几周的工作环境中,我突然看到“SVN commit..”对话框中出现了许多“已更改”的文件,这些文件我绝对没有接触过,而且也没有包含任何真正的差异:

替代文本 http://www.pekkagaiser.de/TortoiseMerge.gif

据我所知,我没有更改这些文件的编码,也没有对它们执行任何其他操作。 有谁知道这是什么以及如何摆脱它?

编辑:该行为再次出现。 Tortoise 声称“文本更改”,即使没有:

替代文本 http://www. stadtpflanzen.de/images/StackOverflow1.gif

替代文本 http://www.stadtpflanzen .de/images/StackOverflow2.gif

这不可能是行结束符,不是吗?这并不紧急,因为现在很少发生,但我仍然很好奇。

编辑:好了各位,是时候承认了。这真的很尴尬,但我知道那是什么了。我没有指出的是,因为我认为这并不重要,我没有在Tortoise的“提交...”对话框中工作,而是在“检查修改”。我想你可以收集其余的内容:我在 IDE 和 Tortoise 之间来回切换了很多次,签入了各种文件,每当我签入文件时,单击刷新,执行其他操作,然后再次签入,因为我忘记了,它不起作用 - 但当然仍然会在列表中。感谢您抽出时间!对每个答案+1,并接受对我印象最久的答案:)

I use TortoiseSVN for version control. In a working cooy I have been working with for weeks, I suddenly see a number of "changed" files showing up in the "SVN commit.." dialog that I have definitely not touched and which do not contain any real differences:

alt text http://www.pekkagaiser.de/TortoiseMerge.gif

I have not changed these files' encodings not performed any other operation on them as far as I can remember.
Does anybody know what this is and how to get rid of it?

EDIT: The behaviour has appeared again. Tortoise is claiming "text change", even though there was none:

alt text http://www.stadtpflanzen.de/images/StackOverflow1.gif

alt text http://www.stadtpflanzen.de/images/StackOverflow2.gif

this can hardly be a line ending thing, can it? It's not urgent as it happens very rarely now, but I'm still curious.

Edit: All right folks, time to own up. It's really embarrassing but I found out what it was. What I didn't point out, because I thought it wasn't important, was that I was not working in the "commit..." dialog of Tortoise, but in "check for modifications". I think you can gather the rest: I switched back and forth a lot between the IDE and Tortoise, checking in various files, and whenever I would check in a file, not click refresh, do something else and check it in again because I forgot, it wouldn't work - but would of course still be in the list. Thanks for your time! +1'ing every answer and accepting the one who stuck with me the longest :)

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

轻许诺言 2024-08-16 00:03:35

您可能使用过 SVN 1.5+ 的新“合并跟踪”功能吗?合并时,它将添加/更改所涉及文件的属性 svn:mergeinfo,甚至是那些未更改的文件。然后这些将显示为要提交的更改。

请参阅 http://svnbook .red-bean.com/en/1.5/svn.branchmerge.basicmerging.html#svn.branchmerge.basicmerging.mergeinfo

Did you maybe use the new "merge-tracking" feature of SVN 1.5+? When merging, it will add/change the property svn:mergeinfo for the files involved, even those that were not changed. These then show up as changes to be comitted.

See http://svnbook.red-bean.com/en/1.5/svn.branchmerge.basicmerging.html#svn.branchmerge.basicmerging.mergeinfo .

执笏见 2024-08-16 00:03:35

在 Repo 浏览器中查看。有一些列显示文件的内容是否已更改,或者文件的属性是否已更改。听起来也许属性已经改变,但文件没有改变。

Look in the Repo-browser. There are columns to show whether a file's contents have changed, or whether a file's properties have changed. It sounds like maybe the properties have changed but not the file.

傲世九天 2024-08-16 00:03:35

好吧,让我们拿出大枪吧。 :-)

将文件(styles.css 修订版 40)检出到单独的目录中。

运行一个程序来计算工作副本和存储库副本上的 md5(例如 md5md5sumopenssl md5)。如果您最终得到不同的答案,则文件会有所不同,并且 TortoiseMerge 不会向您显示重要的内容。如果您最终得到相同的答案(忽略无限可能的情况,即两个不同但非常相似的文件具有两个相同的 md5 哈希值),那么这些文件显然是相同的,并且 TSVN 有一些问题。 (也许它正在查看文件日期?)

编辑:我想到的唯一病态情况是该文件可能具有不同的编码(例如 UTF-8 与 ASCII)...几个月前我从 WinXP SP2 升级到 SP3有时我会遇到奇怪的事情(显然是 UTF-8 字节顺序标记) 前几个字符在文本编辑器中显示得很奇怪。

让我们知道您发现了什么!

All right, let's get out the big guns. :-)

Check out the file (styles.css revision 40) into a separate directory.

Run a program which calculates md5 (e.g. md5, md5sum, or openssl md5) on both your working copy and the repository copy. If you end up with different answers, the files are different and TortoiseMerge isn't showing you something important. If you end up with the same answer (neglecting the infinitesimally probable case where two different but very similar files have two identical md5 hashes), then the files are apparently identical and TSVN has some problem. (maybe it's looking at the file date?)

edit: The only pathological case that crosses my mind is that maybe the file has a different encoding (e.g. UTF-8 vs ASCII)... I upgraded from WinXP SP2 to SP3 several months ago and occasionally I run into weird things (apparently UTF-8 byte order marks) where the first few characters show up strangely in text editors.

Let us know what you find!

╄→承喏 2024-08-16 00:03:35

如果您的文本文件没有将 svn:eol-style 属性设置为 native,并且您刚刚在编辑器中打开它们,然后保存,则行结尾可能会更改他们。

某些编辑器和工具会自动将文件转换为其本机 EOL 版本(例如,将 LF 行尾更改为 CRLF)。

检查此链接以获取有关此属性的完整说明

必须在每个文本文件上手动设置 svn:eol-style ,这就是为什么有一种方法可以通过编辑客户端配置文件来通过文件扩展名自动设置 - 使用 TortoiseSVN 设置、常规设置、编辑subversion配置文件;或检查此链接 并查找 enable-auto-props 条目。

The line endings may change if your text files don't have the svn:eol-style property set to native, and if you just opened them in an editor, then saved them.

Some editors and tools automatically convert files to their native EOL version (for example changeing LF end of lines to CRLF).

Check this link to have a complete description on this property.

The svn:eol-style must be set manually on each text file, which is why there is a way to do that automatically by file extension by editing the client configuration file - use TortoiseSVN settings, general settings, Edit subversion configuration file; or check this link and look for the enable-auto-props entry.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文