有没有更好的方法来处理svn：忽略项目的列表？

对于我们的项目，我们避免在用户的svn配置文件中使用svn

global ignores

，因为这些svn设置仅限于客户端，并且不是项目的属性。我们想要一种方法来管理项目子目录中被忽略的文件，使用类似于

.gitignore

的文件。我开发了一个简单的方案，它使用

.svnignore

文件和一个脚本，该脚本（1）在目录树中查找

.svnignore

文件，并（2）在找到

.svnignore

文件的每个目录上更新

svn:ignore

属性。当有人更新文件时，他们只需要记住运行脚本；我们发现这比手动管理目录上的

svn:ignore

属性更容易

以下是脚本：

#!/bin/sh
# Syntax of the .svnignore file: like what "svn propset svn:ignore" accepts,
# and in addition, lines in the .svnignore file that begin with a pound sign
# (#) are ignored so that one can put comments in the file.

find $1 -depth -name .svnignore | while read file ; do
  dir="`dirname $file`"
  egrep -v '^[  ]*#' $file | svn propset svn:ignore -F - $dir
  svn update $dir
  svn commit --depth=immediates -m"Updated list of ignored files." $dir $dir/.svnignore
done
echo "Done."

以下是此脚本接受的

.svnignore

文件的示例：

# WARNING: This .svnignore file is not understood by SVN directly.
# WARNING: It is meant to be used in conjunction with our script in 
# WARNING: trunk/project/scripts/svn-update-from-svnignore.sh
autom4te.cache
Makefile
config.log
config.status
.deps
include
TAGS
CTAGS
*.o

我的问题是：

有没有更好的方法来完成同样的事情

您在这里看到的方法或脚本是否存在任何危险 谢谢你的提示。

• 我无法理解循环内部的

  svn up

  （以前在WC的根中的单个更新将更优雅）
• 将提交与--depth=immediates相乘也是非常糟糕的想法-为什么不在应用了所有属性更改之后使用单一提交呢
• 查找结果（添加了

  -print0

  ）可以通过管道传送到

  svn propset

  的xargs，从而完全消除了周期
• 传递到脚本WC根目录并在WC根目录中执行（一次）更新和提交（对我来说）似乎不是一个坏主意
• 我无法理解循环内部的

  svn up

  （以前在WC的根中的单个更新将更优雅）
• 将提交与--depth=immediates相乘也是非常糟糕的想法-为什么不在应用了所有属性更改之后使用单一提交呢
• 查找结果（添加了

  -print0

  ）可以通过管道传送到

  svn propset

  的xargs，从而完全消除了周期
• 传递到脚本WC根目录并在WC根目录中执行（一次）更新和提交（对我来说）似乎不是一个坏主意

---

不要这么快就放弃全球市场。您可以通过SVN外部的某种机制来更新它们，例如登录脚本或（在Windows上）全局策略

---

当然，这只有在您有一个集中管理的环境（例如在公司网络中）时才起作用。对于开源项目来说，这是行不通的。但是，无论如何，您可能都不会使用SVN。
不要这么快就放弃全局忽略。您可以通过SVN外部的某种机制来更新它们，例如登录脚本或（在Windows上）全局策略

---

当然，这只有在您有一个集中管理的环境（例如在公司网络中）时才起作用。对于开源项目来说，这是行不通的。但是无论如何，您可能不会使用SVN。
现在对您没有多大帮助，但是Subversion 1.8（在发布时）将具有存储库指定的配置，这将对您有所帮助。特别是1.8将有一个svn:global ignores属性，该属性与global ignores配置选项类似。此外，1.8将具有可继承属性，而svn:global ignores就是这样一个可继承属性。因此，在目录上设置此属性将影响该目录下的任何内容

---

目前对您帮助不大，但Subversion 1.8（在发布时）将具有存储库指定的配置，这将对您有所帮助。特别是1.8将有一个svn:global ignores属性，该属性与global ignores配置选项类似。此外，1.8将具有可继承属性，而svn:global ignores就是这样一个可继承属性。因此，在目录上设置此属性将影响该目录下的任何内容

---

实际上，我们所有的项目都是开源的（使用SourceForge）。诚然，几乎所有的工作都是由我们的（学术、付费）团队完成的，但原则上，它和任何项目一样开放。实际上，我们所有的项目都是开源的（使用SourceForge）。当然，几乎所有的工作都是由我们的（学术的，有偿的）团队完成的，但原则上，它和任何项目一样开放。谢谢！解释：1）如果您试图提交目录的属性，但您的副本不是最新的，svn会抱怨——因此需要svn更新。2） 单个提交的目标是减少意外提交与.svnignore更改无关的子目录中的更改的机会。如果您的回购有子项a/b、a/c和a/d，并且您更改了a/b/.svnignore，但您在其他地方也有更改，那么对于此脚本的目标，您不希望执行“svn提交a”。3） 我同意您可以使用find+xargs，但脚本的可读性和可维护性较差。@mhucka-我将在第一行svn up（在WC的根目录中），在第二行svn status，在status中exit不会显示“Clean WC”。在完成了这个健全性检查之后，我可以提交一次——使用您的代码，我们将有凌乱的日志，并加载了超过所需的服务器（想象一下100-200个子服务器）。简言之，我更喜欢使用干净的工作副本，它更快，服务器压力更小，我的代码更紧凑，在开始时添加一个检查是个好主意。它可以根据您的描述更改脚本，这反过来又会有您提到的优点，所以这是一个改进，毕竟这是我要求的。我会按照你的建议重写。谢谢！解释：1）如果您试图提交目录的属性，但您的副本不是最新的，svn会抱怨——因此需要svn更新。2） 单个提交的目标是减少意外提交与.svnignore更改无关的子目录中的更改的机会。如果您的回购有a/b、a/c和a/d子项，并且您更改了a/b/.svnignore，但是您在其他地方也更改了目标