使用版本控制(SVN、CVS 等)关键字进行程序逻辑

发布于 2024-08-07 17:51:26 字数 536 浏览 9 评论 0原文

现在,在几个项目中,我使用 SVN 关键字来检索有关某些核心文件版本的一些信息。像这样的事情(PHP):

$revision = '$Revision: 1254 $'; // automatically updated each commit
$revision = preg_replace("/[^0-9]/", "");

echo "This file is at revision #" . $revision;

但是我想到,通过检查 $URL$ 关键字输出,我可以判断当前文件是否在标签、分支或主干上,并应用不同的逻辑对程序来说,例如增加缓存时间等。

$svnURL = '$URL: path/to/repo/tags/1.0.1/folder/file.txt $';
if (strpos($svnURL, "/tags/") !== false) {
    echo "Tagged version!";
}

这是否会急剧转向 WTF 领域,或者您认为这种做法可以接受吗?

On a couple of projects now, I've used the SVN keywords to retrieve some information about the version of some core files. Something like this (PHP):

$revision = '$Revision: 1254 

It occurred to me however, by inspecting the $URL$ keyword output, I could tell if the current file was in a tag, branch or on the trunk and apply different logic to the program, eg, increase the cache times, etc.

$svnURL = '$URL: path/to/repo/tags/1.0.1/folder/file.txt 

Is this veering sharply into WTF territory, or would you consider this practice to be acceptable?

; // automatically updated each commit $revision = preg_replace("/[^0-9]/", ""); echo "This file is at revision #" . $revision;

It occurred to me however, by inspecting the $URL$ keyword output, I could tell if the current file was in a tag, branch or on the trunk and apply different logic to the program, eg, increase the cache times, etc.


Is this veering sharply into WTF territory, or would you consider this practice to be acceptable?

; if (strpos($svnURL, "/tags/") !== false) { echo "Tagged version!"; }

Is this veering sharply into WTF territory, or would you consider this practice to be acceptable?

; // automatically updated each commit $revision = preg_replace("/[^0-9]/", ""); echo "This file is at revision #" . $revision;

It occurred to me however, by inspecting the $URL$ keyword output, I could tell if the current file was in a tag, branch or on the trunk and apply different logic to the program, eg, increase the cache times, etc.

Is this veering sharply into WTF territory, or would you consider this practice to be acceptable?

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

扫码二维码加入Web技术交流群

发布评论

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

评论(5

小瓶盖 2024-08-14 17:51:26

嗯,就我而言,这正在转向 WTF 世界。

最好将这些东西配置为应用程序中一般位置的环境变量。

Mm, that's veering into WTF world as far as I'm concerned.

Better off configuring those things as environment variables in a general place in your application.

蓬勃野心 2024-08-14 17:51:26

在我看来,使用 SVN 关键字来影响程序逻辑有点晦涩难懂。我不认为它是病态的,但它肯定需要一些解释性的评论。

另外,在您的示例中,您只需回显相当于版本信息的内容。我从您所写的内容中得知,您实际上打算减少标记版本的缓存时间。由于这有助于调试并且特定于您的内部实践,因此我可以理解为什么您可能想要这样做。

In my opinion, using the SVN keywords to affect program logic is a little bit obscure. I don't feel it qualifies as pathological, but it would surely require some explanatory comments.

Also, in your example, you simply echo what amounts to version information. I take it from what you wrote that you intend actually to decrease the cache time for your tagged version. As that aids debugging and is specific to your internal practices, I can see why you might want to do this.

慢慢从新开始 2024-08-14 17:51:26

在我看来,这是一个非常糟糕的主意。如果您需要配置管理,请使用配置文件和条件来完成。不要依赖源代码控制系统进行配置管理。

This is a really bad idea, IMO. If you need configuration management, do it using configuration files and conditionals. Don't depend on your source code control system for configuration management.

染柒℉ 2024-08-14 17:51:26

这不是一个好主意。实现此目的的更好方法是将分配版本/内部版本号作为持续集成或构建过程的一部分。这可以在 .Net 中通过在构建之前更改 AssemblyInfo.cs 文件来完成。

Not a good idea. A much better way to achieve this would be to assign the version/build number as part of of a continuous integration or build process. This can be done in .Net by changing the AssemblyInfo.cs file before building.

孤凫 2024-08-14 17:51:26

我认为这是不可接受的,因为您可能在将来的某个时候迁移到不同的源代码控制系统,于是这个纸牌屋就会崩溃。它会以一种 (a) 难以检测、(b) 难以修复的方式崩溃。

I would consider this unacceptable, because you may at some point in the future migrate to a different source control system, whereupon this house of cards would come crashing down. It would come crashing down in a way that was (a) hard to detect, and (b) hard to fix.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文