1

I am currently using Mercurial, along with the Guestrepo extension, to manage and version the different components of a project. I have come to a quite stable workflow to manage the different versions of the components.

However, I can't come up with an effective solution when it comes to versioning subtle variations of a component. This is, for example, a slightly different embedded device driver (different serial port speed for example), or a GUI which is written in English instead of German.

I don't think stacking them in the Release/Stable branch is a good workflow, as the proliferation of different configurations (English,Spanish,Chinese,...) could lead to a serious and nonsense bloat of the Release branch.

On the other hand, creating a separate Release branch for each, would lead me to many, many branches, which is not the best solution IMHO.

Creating separate repositories for each of the configurations would suppose a quite tedious task whenever a structural change had to be made, as all of the repos would have to be updated with that change.

Any idea on this?

Thank you.

As @EldadAK suggests, creating a repo for each configuration and importing core functionalities from other repos seems a nice idea.

However, I still can't figure out how to arrange "same but slightly different" components, which differ in some subtle features but share their core.

Is it a code architecture issue? Should the components be refactored so that the main core and the differing features lay in different components, which are related using custom builds for each configuration?

Manex
  • 528
  • 4
  • 15
  • 1
    Personally I would organize my project so that all its variants are in a single branch within a single repository. I would arrange localizations so they are within subfolders inside that main project folder, and I would not maintain branches or repos for different variants. Variant configurations should be configuration options in configuration files. ([UI] section in ini file has language=en-US, [serialPort] baudRate is another section in the ini file) – Warren P Apr 12 '13 at 23:45

2 Answers2

0

IMHO, you should keep all changes in your main branch. Managing all branches or even multiple repositories is not scalable and will eventually get out of hand.

I don't think you should care about the size of your release branch. By keeping it all together, you will always know where you are, what is included in a release and when you really need to branch, have all the changes accumulated to that point.

It's my personal opinion that you should try and keep it simple to manage looking many revisions and years ahead...

Note - Project managers tend to think about next week. You need to think about next year...

I hope this helps.

Eldad Assis
  • 10,464
  • 11
  • 52
  • 78
  • Hi,thanks for the reply. The problem is that, for example, I could come up with an english and a german version (rev 9 and 10), and now need to upgrade a driver which lies on both versions. That inevitably claims branching. – Manex Apr 11 '13 at 14:16
  • 1
    In the language case, I'd manage them as a resource so they can live sided by side and be set by configuration. If you must have a separate branch for each language, I suggest you keep core functionality in a single repository and customizations (language, ui etc.) in dedicated project/effort repositories that import the core artifacts. – Eldad Assis Apr 11 '13 at 14:20
0

effective solution when it comes to versioning subtle variations of a component

While I can't see any serious drawbacks from using named branches in one repo, you can use another ("default" de-facto) solution for configuration management inside Mercurial: MQ

You have only slightly adopt your workflow (same amount of branches, same amount of repos) to MQ

Lazy Badger
  • 94,711
  • 9
  • 78
  • 110