svn on commit 添加额外文件

发布于 2024-12-26 13:24:52 字数 393 浏览 2 评论 0原文

问题是 svn on commit 添加了尚未更新的其他文件。

示例：

svn st

这显示 file1 正在更改

svn commit

这会上传 file1 以及 file2、file3、file4 中的更改

这总是发生在相同的文件上

file2, file3, file4

我怎样才能阻止这个？

SVN版本：

Subversion 命令行客户端，版本 1.6.6

原文

The problem is svn on commit adds additional files which have not been updated.

Example:

svn st

This shows file1 as being changed

svn commit

This uploads the changes in file1 and well as file2, file3, file4

This always happens to the same files

file2, file3, file4

How can I stop this?

SVN Version:

Subversion command-line client, version 1.6.6

分享到QQ

分享到微博

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

发布评论

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

秋凉 2025-01-02 13:24:52

您使用的是哪个版本的 Subversion 客户端？

在 Subversion 1.7 之前的客户端中，Subversion 通过查看文件内容和 .svn 目录中存储的库来确定文件更改。 Subversion 会比较文件本身的属性和内容以确定是否有任何更改。例如：

$ svn up
U file1
U file2
U file3

在此示例中，您将至少看到这六个文件：

.svn/text-base/file1.svn-base
.svn/text-base/file2.svn-base
.svn/text-base/file3.svn-base
.svn/prop-base/file1
.svn/prop-base/file2
.svn/prop-base/file3

它不会查看时间戳来确定文件是否已更改（如 Makefile 那样）。

svn up 和 svn commit 使用相同的算法来确定文件是否应该被记录为被修改。

还有一个名为 .svn/entries 的文件，其中包含该目录所具有的条目列表。这允许 Subversion 跟踪添加和删除，但不用于检测更改。

我在合并期间发现了提交未更改的文件的问题。但是，在执行 svn status 时总会出现这种情况，并且文件内容未更改，但属性 svn:merge info 已更改。

你的问题看起来很不同。首先，在执行 svn status 时您不会看到更改，但它们确实会被提交。如果您在目录上执行 svn -v log 会怎样？文件是否显示为已更改？如果执行 svn status -v 会怎样？这将显示所有文件，包括被忽略的文件和尚未更改的文件。

客户端告诉服务器哪些文件已更改，而不是服务器确定要提交哪些文件。因此，问题在于您的 Subversion 客户端：

您的 Subversion 客户端是什么以及您拥有什么操作系统？我知道 Cgywin 可能会出现问题——尤其是当您与 Windows Subversion 客户端共享工作目录时。在两种不同类型的客户端（例如 GUI 客户端和命令行客户端）之间共享工作目录可能会出现一些问题。例如，VisualStudio 的 AnkhSvn 客户端创建 _svn 目录。 TortoiseSVN 可以使用它们（如果配置正确），但不能使用标准 Subversion 命令行。

当然，1.7 命令行客户端与早期的命令行客户端有很大不同。在标准的 1.7 命令行客户端中，.svn 目录仅位于根目录中，我相信它使用校验和来确定文件的内容是否已更改。

抱歉，我无法提供任何进一步的帮助。也许我给了你一些继续下去的机会？让我知道您的 Subversion 客户端和操作系统，这可能会有所帮助。如果您在同一目录中使用多个 Subversion 客户端，请告诉我。这也可能是一个线索。

我尝试进入 $HOME/.subversion/conf 看看是否有任何设置可能会产生影响，但我没有发现任何会导致此行为的情况。

What version of the Subversion client are you using?

In pre-subversion 1.7 clients, Subversion determines file changes by looking at the content of the file and the stored base in the .svn directory. Subversion compares both the properties and the content of the file itself to determine any changes. For example:

$ svn up
U file1
U file2
U file3

In this example, you'll see at least these six files:

.svn/text-base/file1.svn-base
.svn/text-base/file2.svn-base
.svn/text-base/file3.svn-base
.svn/prop-base/file1
.svn/prop-base/file2
.svn/prop-base/file3

It does not look at the timestamp to determine whether or not a file has changed (like Makefile would have).

Both svn up and svn commit use the same algorithm to determine whether or not a file should be recorded as being modified.

There's also a file called .svn/entries that contains a list of entries that the directory has. This allows Subversion to track additions and deletions, but it is not used for detecting changes.

I've see issues during a merge where an unchanged file is being committed. However, this always shows up when doing a svn status, and the file contents weren't changed but the property svn:merge info was.

Your issue seem very different. First of all, you don't see the changes when doing a svn status, but they do get committed. What if you do a svn -v log on the directory? Do the files show up as being changed? What if you do a svn status -v? This will show all files including ones that are ignored and ones that have not been changed.

It's the client that tells the server what files have been changed, and not the server determining which files to commit. Therefore, the issue is with your Subversion client:

What is your Subversion client and what OS do you have? I know the Cgywin can be problematic -- especially if you share your working directory with the Windows Subversion client. There can be some issues with sharing a working directory between two different types of clients (like a GUI client and a command line client). For example, VisualStudio's AnkhSvn client creates _svn directories. TortoiseSVN can use them (if you configure it correctly), but not the standard Subversion command line.

And, of course, the 1.7 command line client is way different from the earlier command line clients. In the standard 1.7 command line client, the .svn directory is only in the root, and I believe it uses checksums to determine whether or not a file's content has been changed.

Sorry I couldn't provide any further assistance. Maybe I gave you something to go on? Let me know your Subversion client and OS, and that might help. Also let me know if you use multiple Subversion clients in the same directory. That might be a clue too.

I've tried going into $HOME/.subversion/conf to see if there's any setting there that might make a difference, but I found nothing that would cause this behavior.

回复收藏 0 原文