如何配置 Visual Studio 在成功构建后要求提交代码?

发布于 2024-11-13 12:14:05 字数 383 浏览 0 评论 0原文

由于尽早提交是最佳实践,因此经常提交我希望通过一个对话框进行升级,该对话框将要求提交消息并将提交到我正在处理的本地 Mercurial 存储库。
实现此类功能的最简单方法是什么?
如果可能的话,我想避免编写 am 加载项。
我的一个想法是运行一个构建后命令来执行批处理文件。
反过来,批处理文件将检查构建是否成功,然后执行:

hg addremove 

如果没有添加或删除任何内容,则不会请求任何提交消息。如果添加或删除任何文件,它会要求我提供提交消息,一旦输入提交消息,它将执行:

hg commit -m "Insert message here"

是否可能?如果是这样,怎么办?

Since it's the best practice to commit early, commit often I would like to be promoted with a dialog that will ask for a commit message and will commit to my local mercurial repository that I am working on.
What's the easiest way to implement such a feature?
I would like to avoid writing am add-in if possible.
One idea I had is to run a post build command that will execute a batch file.
In turn the batch file will check if the build was successful and then it will execute:

hg addremove 

If nothing was either added or removed, no commit message will be requested. If any files were added or removed it will ask me for a commit message, once the commit message has been inputted it will execute:

hg commit -m "Insert message here"

Is it possible? If so, how?

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

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

发布评论

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

评论(1

っ〆星空下的拥抱 2024-11-20 12:14:05

首先,我怀疑你真的想这样做。

大多数与版本控制相关的模式都表明您想知道更改的内容。我在单个错误修复的实现过程中构建了很多次,但你的问题让我认为你会认为将 N 次提交(其中大多数是不好的)放入你的版本控制系统中是可以的,没有真正的目的。

现在,我同意尽早提交并经常提交是最佳实践,但盲目提交和仅仅因为构建而提交并不是最佳实践。当你得到想要保留的东西时,你应该做出承诺。

话虽如此,您是否尝试过在不带任何参数的情况下执行 hg commit 命令?默认行为是弹出一个文本文件进行编辑(通常通过默认文本编辑器进行编辑),然后等待您将其与新内容一起保存。

换句话说,这应该满足您的要求:

hg commit --addremove

但是,我强烈建议您重新考虑这一点,当您看到充满提交的版本历史记录时,您可能会在某个时候质疑这个决定,这些提交只是在某些期间无休止地来回编辑文件。实验性开发或错误修复。

Visual Studio 也有一些不错的插件,您可能需要考虑这些:

  • VisualHG
  • < a href="http://www.newsupaplex.pp.ru/hgscc_news_eng.html" rel="nofollow">HgSCC

First of all, I doubt you really want to do that.

Most patterns related to version control dictates that you want to know what the change was about. I build many times during the implementation of a single bug-fix, but your question leads me to think that you would think it was OK to get N commits, most of them bad, into your version control system, with no real purpose.

Now, I agree that it is best practice to commit early, and commit often, but it is not a best practice to commit blindly and commit just because it builds. You should commit when you got something you want to preserve.

Having said that, have you tried executing the hg commit command without any arguments whatsoever? The default behavior is to pop up a text file for editing, typically through your default text editor, and wait for you to save it with new content.

In other words, this should do what you want:

hg commit --addremove

However, and I strongly urge you to rethink this, you might question this decision at some point when you see a version history full of commits that are just endlessly editing files back and forth during some experimental development or bugfixing.

There's some good add-ins for Visual Studio out there as well, you might want to consider these instead:

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