使用Mercurial维护CMS和网站 [英] Mantaining a CMS and websites with Mercurial

问题描述

我对水银技术还很陌生，在阅读了一些教程之后，我仍然怀疑什么是最好的方法来做我打算做的事.

我的目标是维护我正在开发的CMS(添加新功能，修复错误等)，并能够轻松地将这些更新分发到我所说的CMS上.

我首先为CMS自己创建了一个存储库，然后当我想创建一个新网站时，克隆CMS存储库并对其进行处理.

现在要提出的问题是:在网站上，存在一些特定于此的更改，并且我也希望在主要CMS存储库中看到这些更改.如何区分它们?

我应该创建一个新分支并将所有网站特定的更改提交给该分支，并将常规更改提交给默认分支吗?还是我应该使用标签?

我正在寻找的一种简单方法是将更改推回CMS存储库，然后继续开发CMS(例如在其他网站中)，并最终用新功能和错误更新使用CMS创建的所有网站可以轻松解决问题.

处理我描述的情况的最佳方法是什么?

谢谢.

解决方案

好吧，您确实提出了至少两个问题(如我所见)

• 如何保持不同的发展路线?
• 如何轻松地将更改从一个(?)DEVEL环境分发到不同的PROD环境.

关于第二个问题的完整最终答案将需要澄清许多具体细节，我建议我们将其推迟一会儿.

在第一个问题上:您是对的，单个回购内站点的命名分支(定期将默认分支与共享更改合并到其中)可能是个不错的选择(不是标签，标签只是更改集的容易记忆的标签). /p>

替代解决方案可以在单个默认分支(每个站点具有单独的mq队列)之上使用 mq

I'm pretty new to mercurial and after reading a few tutorials I'm still doubtful on what's the best way to do what I intend to do with it.

My goal would be to mantain a CMS that I'm developing (adding new features, fixing bugs, etc.) and being able to easily distributes those updates to websites I make with said CMS.

I started by making a repository for the CMS itself, then when I want to make a new website clone the CMS repository and work on it.

Now the questions: working on a website there are changes that will be specific for that and changes that I'd like to see also on the main CMS repository. How to distinguish them?

Should I create a new branch and commit all the website specific changes to that branch and the general changes to the default branch? Or shall I use tags?

What I'm looking for is an easy way to push back changes to the CMS repository, then continue to develop the CMS (in other websites for example) and eventually update all websites I made with the CMS with new features and bug fixes without too much hassle.

What's the best way to deal with the situation I described?

Thanks in advance.

解决方案

Well, you really ask at least two questions (as I see)

• How to maintain diverged lines of development?
• How to easy distribute changes from one (?) DEVEL env to different PRODs env

Full final answer on second question will require to clarify many of the specific details, and I propose that we'll postpone it for a while.

On the first question: you are right, named branches (into which you periodically merge default branch with shared changes) for sites inside single repo may be good choice (not tags, which are only easy memorable labels for changesets).

Alternative solution may use mq on top of single default branch (with separate mq-queues for each site)

这篇关于使用Mercurial维护CMS和网站的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！