【问题标题】:SVN atomic commit how-toSVN 原子提交方法
【发布时间】:2009-05-03 10:15:35
【问题描述】:

我在哪里:Linux 命令行

我现在遇到的问题:

有时我无法进行原子提交(包含一个特定工单/任务所需的所有修改),因为我们在存储库中有一些文件,其内容因本地开发环境而异。

例如:database.xml(数据库名称、用户名、密码等)。我在本地环境中修改了这个文件,每次我需要提交/签入时,我都会手动列出提交所需的所有文件/文件夹(不包括这个本地修改的文件)。

也许这是一个错误的设计决定,database.xml 必须从存储库中删除并更改为database.xml.template(存储在 SVN 中),因此在您手动执行 svn add 之前不会包含此文件以提交为了它?也许这是错误的方法 - 将所有这些环境相关信息存储在存储库中 - 在这种情况下,我们可以通过提交修改后的配置来破坏一切,例如..

据我了解,svn:ignore 属性在这种情况下无济于事,因为它只能用于未存储在存储库中的文件..

如何解决这个问题?

P.S.:我使用的是 Ubuntu,主要是纯命令行的 SVN。

【问题讨论】:

  • 我同意在 Subversion 中保留一个.template 文件,并且只在本地保留真实配置、修改版本。重要的是,开发人员应该永远修改个人配置以外的真实配置文件。也就是说,如果要向文件中添加新选项,则必须将其添加到 .template 文件中,然后从中重新创建自己的配置文件(可能会自动从 .template 文件中重建配置)简化工作的脚本)。
  • 是的,我在 SVN 中有 database.xml.template,在本地结帐中有 database.xml.override 并被忽略,还有一个将两者结合起来生成 database.xml 的脚本。至少,如果我有时间编写脚本,我会这样做;-) 否则开发人员必须在每次 database.xml.template 更改时手动合并到 databaes.xml。
  • 事实上,如果开发人员想要真正花哨,那么可以将 database.xml.override 设置为指向他们在存储库的个人分支中进行版本控制的文件的硬链接,这样个人配置就是也被控制了。
  • 在某些情况下,我们在版本控制文件中使用特殊关键字:USER 代表用户名,PASSWORD... 然后只是一个简单的 sed:“sed -e 's/USER/my_username/' -e 's /PASSWORD/my_passwd' config_template > config.xml" 更新文件。

标签: svn version-control svnignore


【解决方案1】:

“标准”程序是这样的(原谅 SVN 语法,我最近一直在使用 Bazaar):

echo config > database.xml.template
svn add database.xml.template
svn ignore database.xml
svn commit

然后在每个人的开发机器上:

svn checkout
cp database.xml.template database.xml
...edit database.xml...

当他们提交时,

echo foo > someotherfile
svn commit

database.xml 文件不会被添加到 Subversion。

【讨论】:

  • 让 svn 忽略 database.xml 的实际命令是“svn propset svn:ignore database.xml”。 (从 svn 1.5.5 开始)
  • 如果我没记错的话,使用 propset 将覆盖所有其他 svn:ignore。您可以尝试将 propget 和 propset 组合起来,或者更简单地使用 propedit 并使用编辑器添加另一行。
【解决方案2】:

您应该在存储库中存储一个模板,而不是您需要在本地修改的实际文件。

这样,您可以在需要时重建原始文件,而不会冒险将文件存储到不应该存在的存储库中。

不,svn:ignore 在这里帮不了你。

【讨论】:

    【解决方案3】:

    我的 2 美分:首先,您需要确保是否有任何(简单的)方法可以为参与项目的所有开发人员协调您的路径。这可能是相同的相对目录结构或应用程序中的某个薄层,它支持一些 shell 变量或诸如 $home、%USERPROFILE% 等。随着时间的推移,这将比让每个开发人员处理它自己的未版本化配置和这也是 IDE 试图提供的。

    一般来说,版本控制配置文件对我来说非常好,只是开发人员花时间进行设置,不应该意外丢失。

    【讨论】:

      猜你喜欢
      • 2011-11-26
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2017-12-19
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2020-04-15
      相关资源
      最近更新 更多