使用 Dreamweaver 时 Subversion 无法合并更改
我正在运行一个项目，我们使用 SVN 作为版本控制。有 3 名开发人员。
Dev1 = OSX + Textmate
Dev2 = Windows 7 + Dreamweaver（加上 tortoise svn）
Dev3 = OSX + Coda
情况 1（预期）：
Dev1 和 dev3 处理一个名为signup.php 的文件。他们处理文件的不同部分。 Dev1 提交它，dev3 更新他们的副本。 signup.php 按预期合并。一切都好。
情况 2（非预期）：
Dev1 和 dev2 处理一个名为signup.php 的文件。他们处理文件的不同部分。 Dev1 提交它，dev2 更新他们的副本。即使处理文件的不同部分，signup.php 始终会发生冲突。这不是 dev1 和 dev3 所经历的预期行为。这是双向的，每次 dev1 更新 dev2 的更改时，他也会遇到冲突。但从来没有使用 dev3。
这可能是 Dreamweaver 保存文件的方式所致吗？也许是字符编码。我们都在UTF8 下工作。
这些持续不断的、不必要的冲突正在成为一种巨大的干扰。帮助 ！
I've got a project running and we're using SVN as the version control. There are 3 devs on it.
Dev1 = OSX + Textmate
Dev2 = Windows 7 + Dreamweaver (plus tortoise svn)
Dev3 = OSX + Coda
Case 1 (expected):
Dev1 and dev3 work on a file called signup.php. They work on different parts of the file. Dev1 commits it and dev3 updates their copy. signup.php is merged as expected. All good.
Case 2 (not expected):
Dev1 and dev2 work on a file called signup.php. They work on different parts of the file. Dev1 commits it and dev2 updates their copy. signup.php is always in conflict even though different parts of the file are worked on. This is not the expected behaviour experienced by dev1 and dev3. This works boths ways and each time dev1 updates dev2's changes he gets conflicts too. But never with dev3.
Could this be down the way Dreamweaver is saving files ? Perhaps character encoding. We are all working in UTF8.
These constant and unnecessary conflicts are becoming a massive distraction. Help !
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这可能是由于 Windows 和 OS X 之间的行结尾编码不同：无论开发人员如何更改，整个文件的行结尾都会更新为平台本机的内容。
This might be due to line endings being encoded differently between Windows and OS X: whatever the developers change, the entire file's line endings get updated to what's native for the platform.
该文件有哪些 svn 属性？
如果它的 svn:mime-type 属性集不以“text/”开头，则 Subversion 会将该文件视为二进制文件，并且您始终必须手动解决冲突。
What svn properties does this file have?
If it has a svn:mime-type property set that doesn't start with 'text/' than Subversion sees the file as binary and you will always have to resolve conflicts by hand.