源代码控制分支需求 [英] Source control Branching needs

问题描述

我们正在开发医院信息系统软件.该项目将因医院而异，包含不同的用例.但是很多部分都是一样的.所以我们将使用源代码控制的分支机制.如果我们在一家医院发现了一个bug，我们怎么知道其他分支机构是否也有同样的bug.

we are creating hospital information system software. The project will be different hospital to hospital and contain different use cases. But lots of parts will be the same. So we will use branching mechanism of the source control. If we find a bug in one hospital, how can we know the other branches have the same bug or not.

图像 http://img85.imageshack.us/img85/5074/version.png

我们所附图片中的数字显示了每个医院的软件.

The numbers in the picture which we attached show the each hospital software.

你有解决这个问题的方法吗?

Do you have a solution about this problem ?

哪个源代码控制(SVN、Git、Hg)适合解决这个问题?

Which source control(SVN,Git,Hg) we will be suitable about this problem ?

谢谢.

推荐答案

好吧，这不是真正的 VCS 问题，这是首要的架构问题 - 您如何在这样的环境中构建和构建您的应用程序您可以根据需要将特定用例交付给每家医院，同时能够按照您的建议修复通用代码中的错误.

Ok, this is not really a VCS question, this is first and foremost and architectural problem - how do you structure and build your application(s) in such a way that you can deliver the specific use cases to each hospital as required whilst being able, as you suggest, to fix bugs in commom code.

我认为可以肯定地说，如果您遵循图片中建议的模型，您将无法始终如一地有效地这样做.您最终会得到许多不同的、离散的、必须单独维护的应用程序，即使它们在某些时候来自一组公共代码.

I think one can state with some certainty that if you follow the model suggested in your image you aren't going to be able to do so consistently and effectively. What you will end up with is a number of different, discrete, applications that have to be maintained separately even though they have at some point come from a common set of code.

很难做出更好的概括但是我认为这将是以下几行:

Its hard to make more than good generalisations but the way I would think about this would be something along the following lines:

首先，您需要一个核心应用程序(或一组应用程序或一组应用程序库)，这些将构成任何交付系统的基础，因此是一组维护的代码(尽管该核心本身可能包含外部库).

Firstly you need a core application (or set of applications or set of application libraries) these will form the basis of any delivered system and therefore a single maintained set of code (although this core may itself include external libraries).

然后，您可以为自定义应用程序(每个医院实例)提供多种选项，您可以通过多种方式定义可用功能:

You then have a number of options for your customised applications (the per hospital instance) you can define the available functionality a number of means:

• 在一个极端情况下，通过配置 - 拥有一个包含所有代码的应用程序，并在每个实例的基础上有效地打开和关闭事物.
• 另一种极端情况是，每个医院都有一个应用程序，其中基本上包含具有自定义功能的核心代码.

然而，虽然每家医院的用例总和不同，但个别用例在多个实例中是通用的，因此您需要瞄准模块化系统，即从共同核心开始的东西可以通过组合和任何其他方式进行扩展和配置.

However the likelyhood is that whilst the sum of the use cases for each hospital is different individual use cases will be common across a number of instances so you need to aim for a modular system i.e. something that starts with the common core and that can be extended and configured by composition as much as by any other means.

这意味着您可能希望广泛使用控制反转和依赖注入，以在通用框架内为您提供灵活性.您想查看可扩展性框架(我使用 .NET，所以我会查看托管可扩展性框架 - MEF)，它允许您在运行时而不是在编译时以某种方式组装"应用程序.

This means that you are probably want to make extensive use of Inversion of Control and Dependency Injection to give you flexibility within a common framework. You want to look at extensibility frameworks (I do .NET so I'd be looking at the Managed Extensibility Framework - MEF) that allow you to go some way towards "assembling" an application at runtime rather than at compile time.

您还需要注意您将如何部署 - 尤其是您将如何更新 - 您的应用程序，此时您是对的，您需要同时拥有版本控制和您构建环境正确.

You also need to pay attention to how you're going to deploy - especially how you're going to update - your applications and at this point you're right you're going to need to have both your version control and you build environment right.

一旦你知道你将如何构建你的应用程序，那么你就可以查看你的版本控制系统 - @VonC 当他说关键特性是能够将共享项目中的代码包含到多个可交付项目中时.

Once you know how you're going build your application then you can look at your version control system - @VonC is spot on when he says that the key feature is to be able to include code from shared projects into multiple deliverable projects.

如果是我，现在，我可能会有一个核心(它本身可能是多个项目/解决方案)，然后每个医院有一个项目/解决方案，但我的目标是尽可能少地编写代码每个医院项目 - 理想情况下，框架足以定义特定于实例的配置和 UI 自定义

If it were me, now, I'd probably have a core (which will probably itself be multiple projects/solutions) and then one project/solution per hospital but I would be aiming to have as little code as possible in the per hospital projects - ideally just enough framework to define the instance specific configuration and UI customisation

至于使用哪个...如果您是一家 Microsoft 商店，那么请仔细研究 TFS，拥有良好集成环境所带来的生产力收益是相当可观的.

As to which to use... if you're a Microsoft shop then take a good long hard look at TFS, the productivity gains from having a well integrated environment can be considerable.

否则(无论如何)，在我看来，DVCS(Mercurial、Git、Bazaar 等)在更传统的系统上随着它们的成熟而获得优势.我认为 SVN 是一个出色的工具(我使用它并且它有效)，并且我认为您需要一个用于此类开发的中央存储库 - 尤其是因为您需要某个地方来触发您的持续集成服务器 - 但是您可以实现相同的目标DVCS 以及在不破坏构建"的情况下进行频繁的本地、增量提交的能力以及 DVCS 为您提供的灵活性意味着如果您有选择 现在 那么这几乎肯定是go(但您确实需要确保建立良好的实践，以确保尽早将代码推送到您的核心存储库)

Otherwise (and in any case), DVCS (Mercurial, Git, Bazaar, etc) seem to me to be gaining an edge on the more traditional systems as they mature. I think SVN is an excellent tool (I use it and it works), and I think that you need a central repository for this kind of development - not least because you need somewhere that triggers your Continuous Integration Server - however you can achieve the same thing with DVCS and the ability to do frequent local, incremental, commits without "breaking the build" and the flexibility that DVCS gives you means that if you have a choice now then that is almost certainly the way to go (but you do need to ensure that you establish good practices in ensuring that code is pushed to your core repositories early)

我认为纯粹从 VCS 问题中仍有很多需要解决的问题 - 但是除非您知道如何构建交付的解决方案，否则您无法详细了解这些内容.

I think there is still a lot to address purely from the VCS question - but you can't get to that in useful detail 'til you know how you're going to structure your delivered solution.

这篇关于源代码控制分支需求的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！