有时,当您使用本地副本时,可能会存储您不希望提交的配置设置,并且忽略文件是不切实际的,因为它还包含特定于应用程序的设置。如何在做颠覆提交之前清理源代码?
例如,Django settings.py文件包含数据库连接详细信息和项目设置,例如要加载的应用程序。
当提交这些类型的文件时,有没有办法消毒这些类型的文件?有没有办法在再次结账时恢复您自己的本地设置?
我现在的环境是Linux和命令行Subversion
有时,当您使用本地副本时,可能会存储您不希望提交的配置设置,并且忽略文件是不切实际的,因为它还包含特定于应用程序的设置。如何在做颠覆提交之前清理源代码?
例如,Django settings.py文件包含数据库连接详细信息和项目设置,例如要加载的应用程序。
当提交这些类型的文件时,有没有办法消毒这些类型的文件?有没有办法在再次结账时恢复您自己的本地设置?
我现在的环境是Linux和命令行Subversion
解决此问题的一种方法是将“标准”配置文件完全保留在不同的文件中,例如settings.py.example
。在您的工作副本中,您将复制settings.py.example
至settings.py
并使用副本。如果您需要更改标准配置,请更改settings.py.example
并将其签入。否则,您不需要更改它,并且修改的settings.py
甚至不在版本控制中,因此它不会被注意到(您可以将其包含在svn:ignore
属性中以使其更加安静)。
我用忽略-ON-commit的更改。
虽然这似乎是特定于TortoiseSVN。可能无法在命令行上使用。
以下是我如何避免此问题。通常我有开发,UAT(用户验收测试)和生产配置。通常它们并排存在于相同的目录中(或者可能是单独的dev/UAT/prod目录)。这些都被检入并对待源代码。因此,可以单独管理dev/UAT/prod数据库配置(例如)。
开发发生指向开发配置(但你选择这样做)。自动测试将跑出开发或UAT CONFIGS(取决于项目等)
此外,我还提供通过设置我的系统来检查我的主目录之前来装载这些CONFIGS覆盖的手段,我可以提供真正个人化的覆盖。通常重写配置只会指定一部分变量,所以dev/UAT/prod配置可以更改和增长,而我的个人配置不需要跟踪更改。我个人的覆盖不是通过SVN或类似的控制,因为它特别针对我在那个特定时间做的事情。
不知道UAT是什么。看着它 - 用户验收测试? – 2009-07-25 13:08:18
谢谢Greg。有时解决方案很明显,你想知道为什么你自己没有想到它) – 2009-07-25 22:30:02