Project Common Orbiter Installation

[Face]

Hy there,

in the past years - while doing some Orbiter development and running open source projects - I have quickly become familiar with version control systems. At first it was CVS, then SVN, now Mercurial and Git...
In all those years I used them not only to version my code, but - almost naturally - to version my Orbiter environment, too.

Thinking about that, it left me with the feeling that this might be a nice solution for managing addons in Orbiter. So let me propose the

Common Orbiter Installation (COI) system
Using a distributed version control system for a radically new way of dealing with addons.

Let me start with the use cases I'm following to put my Orbiter environment under source control. I will skip installation of DVCS programm and such and only focus on the use cases themself. Just be aware of "hg" being the command-line tool used as DVCS programm...

First I put the base distribution under source control:

• Create a dir for it - let's say "C:\Orbiter"
• > cd C:\Orbiter
• > hg init
• Unzip Orbiter's base package to the dir
• > hg addremove -s 100 (adds all files to the repository and detects copies or renames)
• > hg ci -m "Base" (commits this first changeset with comment "Base")
• > hg tag -l "Base" (tags the commit with the name "Base" locally)

Then I put addon 1 under source control:

• Unzip addon 1
• Follow addon-instructions to modify base files etc.
• > hg addremove -s 100
• > hg ci -m "addon 1"
• > hg tag -l "addon 1"

Then I want to put addon 2 under source control (it can run without any other addon installed):

• > hg up Base
• Unzip addon 2
• Follow instructions to modify
• > hg addremove -s 100
• > hg ci -m "addon 2"
• > hg tag -l "addon 2"

Then I want to add addon 3 that depends on addon 1:

• > hg up "addon 1"
• Unzip addon 3
• Again modify
• > hg addremove -s 100
• > hg ci -m "addon 3"
• > hg tag -l "addon 3"

Then I want to add addon 4 that depends on both addon 1 and addon 2:

• > hg up "addon 1"
• > hg merge "addon 2"
• Solve conflicts
• > hg ci -m "addon 1 and 2"
• Unzip addon 4
• Modify
• > hg addremove -s 100
• > hg ci -m "addon 4"
• > hg tag -l "addon 4"

So my repository version graph looks like that:

  *   addon 4
  |
  *   addon 1 and 2
  |
* |   addon 3
| |\
| | * addon 2
 \| |
  * | addon 1
  |/
  * base

If I list my tags, i'll get this:
> hg tags
base
addon 1
addon 2
addon 3
addon 4

If I want to play with an addon, let's say 2, I just issue hg up "addon 2" and the dir will be reset to that state where addon 2 was installed.

If I want to play with all addons concurrently, i'd have to first check how many parallel "heads" there are:
> hg heads
addon 4
addon 3
Then I make a special revision, where i put together 2 heads with hg merge "addon 3" "addon 4". Now I can play around with it, or "save" this merge via hg ci -m "addon 3 and 4".

The nice thing here is, that whenever a conflict occurs - let's say both addon 3 and addon 4 modify the base.cfg file - the system launches a graphical merge tool and let the user decide what to do AFTER automatically solving obvious conflicts. Most of the time, you won't have to do anything...

The next thing to do would be a nice UI - shielding me from the version control chitchat... this would basically automate the above mentioned commands to a point where there are dialogs for
* adding/removing,
* activate/deactivate and
* upload/download addons

And now for the cool part: this can all be scaled up to something like OH, i.e. a common installation, where all addons are stored in installed manner, and where everyone can "pull" revisions from to "install" it in his/her system.

Imagine the above mentioned graph on 3 machines... the Common Orbiter Installation (COI) server, user 1 and user 2:

COI has

*   addon 3
|
| * addon 2
| |
* | addon 1
|/
* base

User 1, an addon-developer has

*   addon 4
|
*   addon 1 and 2
|\
| * addon 2
| |
* | addon 1
|/
* base

User 2, the regular addon-user has

* addon 1
|
* base

User 2 uses the upload/download dialog mentioned above to get a list of all addons on the COI server... he'll get something like this:

Installed:
base
  |
  + addon 1

Available:
base
  |
  + addon 3

User 1 uses the upload/download dialog to get a list of all addons FOR the COI server... he'll get something like this:

Installed:
base
  |
  + addon 1

New:
base
  |
  + addon 1 and 2
              |
              +         addon 4

User 1 selects addon 4 and uploads it.
The next day, user 2 again checks COI...

Installed:
base
  |
  + addon 1

Available:
base
  |
  + addon 3
  |
  + addon 1 and 2
              |
              +         addon 4

He thinks "hey cool, addon 4 sounds promising" and selects it and downloads it. His graphs will look like this then:

*   addon 4
|
*   addon 1 and 2
|\
| * addon 2
| |
* | addon 1
|/
* base

Then he uses the select/unselect dialog to select addon 4 (or the recently downloaded addy is selected automatically) and immediately has a orbiter dir with all files set up properly to start orbiter right away. No install hazzle, no addon conflicts...

With this system you have some pretty neat advantages:

• efficient packing of addons
• efficient transportation via network
• assembling of dependencies is on developer side, not user side
• fast and secure "installation"/"deinstallation" of addons
• versioning implicit (of course)
• crypthographical signing is possible to authenticate "installations"
• due to lightweight server integration, everyone can be a server and interact with other users directly to e.g. exchange intermediate development snapshots

Obviously, there are some disadvantages, too:

• the need to learn yet-another-addon-installer (although the system can easily provide a ready-to-use snapshot download in ZIP format - see http://bitbucket.org/face/orrl/get/tip.zip for example)
• Developers have to distribute "installed" addons instead of addon packages with installers (well, this can be an advantage, too)
• Licensing problems may surface - see DanSteph's OrbiterSound and OH

I'll try to come up with a first proof-of-concept for the GUI.

Questions or suggestions are welcome!

regards,
Face

 

[Fizyk]

This looks really awesome.

 

[wehaveaproblem]

Hey Face mate,

I don't understand all the technical bits, but this is a fantastic idea, a truely communal project.

Your work on the ORRL (I know I haven't been around in a while, but we should have a race sometime soon) was top notch, so I'm confident you could pull this off.

In expectation of a future poll, I vote YES.

 

[Face]

Small update...

Worked a bit more on the idea and made a simple GUI mock-up - see attachment:

• the left side is the client side, the right side the server end... just like with WinSCP etc.
• the yet empty tree views will contain the appropriate addon list with checkboxes to select them
• the upper tool strips contain the local location field, local refresh and server URL field, server refresh respectively
• the vertical tool strip contains (from top to bottom) the start button (to start the configuration process towards the selected composition), the up- and download as well as the add and remove buttons
• the lower strip contains progress-bars for local and remote actions, respectively

I think this layout is clean enough to be of use...

The second attachment shows an example graph of a COI repository. The COIClient project is self hosting .

regards,
Face

BTW: The choice for icon picture was easy enough... a KOI :lol: .

 

[ar81]

As I see it the problem could be that many newcomers are not developers.
They are not used to the word "dependency".
So if it was possible to create a software to pack and check dependencies before packing, it would be very useful.

 

[tblaxland]

As I see it the problem could be that many newcomers are not developers.
They are not used to the word "dependency".
So if it was possible to create a software to pack and check dependencies before packing, it would be very useful.

Face's point was that the developer would need to define the dependencies. The noob would just need to know that he wants addon 4 and the DVCS takes care of the dependencies for him.

Face, I am a noob when it comes to DVCS implementation but this sounds pretty cool. Would the COI be tool-independant? In other words, could I use some DVCS tool other than hg/COI-client to inspect and/or commit to the repository? Also, how do you control commits so we don't end up with rubbish on the system?

 

[TSPenguin]

Obviously this is a great project.

Face was so kind to point me to this video way back. It explains the advantages of git (hg is very very similar) in very good terms. It is held by Linus Torvalds, the creator of linux and git.

(Yes, he really hates CVS. A LOT!)

Edit: since he mentiones it so late, mercurial = hg.

 

[Face]

Face's point was that the developer would need to define the dependencies. The noob would just need to know that he wants addon 4 and the DVCS takes care of the dependencies for him.

Exactly. The concept of dependencies is not propagated to the user anymore. I always thought that the whole dependency thing is quite confusing, because all you want to have is a directory containing all the right files in the end.
All the dependency-hazzle is shifted to the developer - where it belongs to IMHO, because the developer anyway uses the proper addon-environment.

On of the problems for noobs are collisions, though. You can have addons not compatible with each other, and the natural response to such problems always is to create another vanila Orbiter install and separate addons. And this is exactly what a DVCS can do for you. Either via cheap and fast filesystem-cloning, or via in-tree branching. And if you absolutely have to have two colliding addons together, the system even supports you in merging it.

The point of the COIClient is to shield this DVCS terms from the casual user and just provide a clean "I want this and that... and those, too" interface.

Face, I am a noob when it comes to DVCS implementation but this sounds pretty cool. Would the COI be tool-independant? In other words, could I use some DVCS tool other than hg/COI-client to inspect and/or commit to the repository? Also, how do you control commits so we don't end up with rubbish on the system?

Yes, it can be made tool-independent, but at first I'd like to have a quick proof-of-concept, where I can work out the needed operations with a DVCS I'm very familiar with... Mercurial.
Since many of the basic concept like merging, branching/bookmarking, tagging and rebase are common among the big three (bzr, git, hg), it should be fairly easy to make the whole thing DVCS-agnostic in the end.
BUT: once you have a COI-system running, you have to stick with the backend. It would be almost impossible to have a common wire-protocol.
I really see the COIClient as frontend only to the underlying DVCS-infrastructure and don't want to implement yet another DVCS system.

As for the commit control... with a DVCS infrastructure, there are many possible ways to handle uploads:

1. Central repository with "pull" and "push" access, i.e. trusted members are allowed to download and commit what they want. This is really only possible with a small user-base, say up to 20 or so.
2. Central repository with open "pull" access, but "push" access only for a small group of admins and previewers. Developers have to send "pull"-requests, bundles or patches to previewers, who either forward the addons directly to the repository or integrate them properly. IIRC, this is in a way similar to OH...
3. No central repository, but a network of trust... NASSP-folks are hosting their stuff, DanSteph the DG-series, DBeachy the XR-series and so on. The user will have to contact those repos separately and download the wanted addons. Similar to what linux package managers do...

I think the best would be to start with 3 and then - if the system matures - go to 2.
But this is really only a social agreement, no technical issue.

regards,
Face

 

[wehaveaproblem]

Quick question Face. Some addons require edit's of a file rather than replacement, how will the system handle this?

I'm thinking of the addition of base textures or NAV frequencies for example.

 

[Face]

Quick question Face. Some addons require edit's of a file rather than replacement, how will the system handle this?

I'm thinking of the addition of base textures or NAV frequencies for example.

You see, THIS is the big advantage here... all you do is checkpointing your whole Orbiter installation directory, including all changes to base file etc. OFC the DVCS divides it into deltas under the hood, but from the users view, adding an addon would be making a snapshot of your current development environment as a whole (including the addon of course).

And this is where dependencies come in... if you develope an addon that uses other addons, what do you do? You simply set-up an Orbiter environment with all these other addons you need to run and hack away...
In COI-terms, it would be selecting those other addons, in DVCS-terms it is checking-out a revision where all those addons are present...

If you then decide to publish this exact state of your environment, you add the addon via COI, which is nothing else but a commit in DVCS-terms (on top of the previously checked-out revision). If someone else is downloading this addon from you and select it, he will get into the EXACT same state of environment as you where in developing it. So the whole dependency-shebang is obsolete. Instructions to modify base-files is then obsolete, too.
A problem is, if the user wants to use your addon together with some other addon... in COI-terms he selects multiple addons... in DVCS-terms he need to merge two revisions.
With SVN/CVS this was nearly impossible, but in DVCS, automatic merging with only minimal need for human conflict-solving is top notch.

Imagine your addon is using a base.cfg texture named "rooftop". Some other addon is using that, too, but with different content.
Now you base your addon on a plain Orbiter install, the other one too... Both addons are distributed, and some user gets both and wants to use both in the same environment. With COI, he can either select the one or the other, with the Orbiter environment automatically "switching" the needed files. Or he can select both, therefore instructing COI to merge both addons... which will lead to the conflict being exposed to the user: "rooftop.dds conflict - use from addon 1 or addon 2?". A noob would say "damn, not possible to use them together, I have to ask the author" and can continue to use either the one or the other without loosing something. An advanced user (or the author) would go and rename/move one addon's texture just for this special purpose, creating an merge named "addon 1 and addon 2". Other users can than use this merge by downloading it. The next time they select both 1 and 2 together, the merge will be used.

As you can see, with this system the complexity of compatibility of addons is shifted away from the users towards the developers. Maybe they'll hate me for that, then :rofl:

regards,
Face

 

[tblaxland]

Yes, it can be made tool-independent, but at first I'd like to have a quick proof-of-concept, where I can work out the needed operations with a DVCS I'm very familiar with... Mercurial.
Since many of the basic concept like merging, branching/bookmarking, tagging and rebase are common among the big three (bzr, git, hg), it should be fairly easy to make the whole thing DVCS-agnostic in the end.
BUT: once you have a COI-system running, you have to stick with the backend. It would be almost impossible to have a common wire-protocol.
I really see the COIClient as frontend only to the underlying DVCS-infrastructure and don't want to implement yet another DVCS system.

That all makes sense. Windows support for Mercurial seems better as far as I can tell so it seems a logical choice.

As for the commit control... with a DVCS infrastructure, there are many possible ways to handle uploads:

1. Central repository with "pull" and "push" access, i.e. trusted members are allowed to download and commit what they want. This is really only possible with a small user-base, say up to 20 or so.
2. Central repository with open "pull" access, but "push" access only for a small group of admins and previewers. Developers have to send "pull"-requests, bundles or patches to previewers, who either forward the addons directly to the repository or integrate them properly. IIRC, this is in a way similar to OH...
3. No central repository, but a network of trust... NASSP-folks are hosting their stuff, DanSteph the DG-series, DBeachy the XR-series and so on. The user will have to contact those repos separately and download the wanted addons. Similar to what linux package managers do...

I think the best would be to start with 3 and then - if the system matures - go to 2.
But this is really only a social agreement, no technical issue.

regards,
Face

If I understand this correctly, 2 & 3 are much the same thing anyway just 3 is more distributed. Currently, OH is more like 1 - once you have had your first addon approved you can upload to your heart's content.

It would seem that the server workload should be less for such a system than for something like OH. What would the workload for a repo admin be like? It all seems pretty automated.

With regard to the client, as it stands what you have presented is very plain compared to the preview content you get on OH (no criticism, just an observation). Is there some way the client could be communicate with a web browser (or be a plugin?) so that you could browse addons with the richness that OH currently offers but with the control of COI? A list of 2,521 available addons identified by name only is not very informative as to whether or not I should expend my bandwidth for one of them

If you then decide to publish this exact state of your environment, you add the addon via COI, which is nothing else but a commit in DVCS-terms (on top of the previously checked-out revision). If someone else is downloading this addon from you and select it, he will get into the EXACT same state of environment as you where in developing it.

It seems the implication is that if I want to publish my addon, I should develop it (or least publish it) uses the most vanilla Orbiter install that is required for the addon to run. Going back to your example above, say I have this environment:

[FONT=Courier New]
  *     addon 4
  |
  *     addon 1 and 2
  |
* |     addon 3
| |\
| | * addon 2
 \| |
  * | addon 1
  |/
  * base[/FONT]

Say I decide to whip up addon5 in that environment. addon5 happens to not depend on anything but base. Once I have written it in that environment, it would seem that a dependency on addons 1-4 would be implied once I take a snapshot of that environment, like this:

[FONT=Courier New]
  *   addon 5
  |
  *   addon 4
  |
  *   addon 1 and 2
  |
* |   addon 3
| |\
| | * addon 2
 \| |
  * | addon 1
  |/
  * base[/FONT]

How to get to the following from what I had above?

[FONT=Courier New]
*       addon 5
|   
|   *   addon 4
|   |
|   *   addon 1 and 2
|   |
| * |   addon 3
| | |\
\ | | * addon 2
 \ \| |
  \ * | addon 1
   \|/
    * base[/FONT]

As you can see, with this system the complexity of compatibility of addons is shifted away from the users towards the developers. Maybe they'll hate me for that, then :rofl:

Well, it will solve many of the inevitable "your addon doesn't work" type posts when a user has not resolved dependcies properly. Generally developers are pretty good at documenting dependencies anyway. To me, this system seems to reduce the workload because all they have to do is commit a "works on my computer" environment.

 

[Face]

It would seem that the server workload should be less for such a system than for something like OH. What would the workload for a repo admin be like? It all seems pretty automated.

For a central repo in the ranks of OH there would still be enough to do. And the web interface itself has to be maintained anyway, since this is only a "headless" infrastructure that can be used by the web interface.

With regard to the client, as it stands what you have presented is very plain compared to the preview content you get on OH (no criticism, just an observation). Is there some way the client could be communicate with a web browser (or be a plugin?) so that you could browse addons with the richness that OH currently offers but with the control of COI? A list of 2,521 available addons identified by name only is not very informative as to whether or not I should expend my bandwidth for one of them

Indeed. I just don't see COI as replacement for OH, but as infrastructure. It is possible to apply tags to addon-commits in such a way that the tag is a link to a website. On selecting the node in COI's tree-view, a browser-control can display the appropriate link. In addition, another tag can contain a link to the internal documentation of the addon, e.g. a pdf or readme. This can be displayed in appropriate controls, too.
I can imagine various ways to enhance the appearance, but for now I'd like to stay with the plain name for speed's sake.

It seems the implication is that if I want to publish my addon, I should develop it (or least publish it) uses the most vanilla Orbiter install that is required for the addon to run. Going back to your example above, say I have this environment:

[FONT=Courier New]
  *     addon 4
  |
  *     addon 1 and 2
  |
* |     addon 3
| |\
| | * addon 2
 \| |
  * | addon 1
  |/
  * base[/FONT]

Say I decide to whip up addon5 in that environment. addon5 happens to not depend on anything but base. Once I have written it in that environment, it would seem that a dependency on addons 1-4 would be implied once I take a snapshot of that environment, like this:

[FONT=Courier New]
  *   addon 5
  |
  *   addon 4
  |
  *   addon 1 and 2
  |
* |   addon 3
| |\
| | * addon 2
 \| |
  * | addon 1
  |/
  * base[/FONT]

How to get to the following from what I had above?

[FONT=Courier New]
*       addon 5
|   
|   *   addon 4
|   |
|   *   addon 1 and 2
|   |
| * |   addon 3
| | |\
\ | | * addon 2
 \ \| |
  \ * | addon 1
   \|/
    * base[/FONT]

The transition you posted above is called "rebase". It takes the differences of "addon 5" to "addon 4" and applies it to "base", creating a new changeset "addon 5" on top of base. Then, the changeset on top of "addon 4" is deleted.

OFC, if you are developing a new addon which you know should work based on "base" only, why not update to that environment by deselecting all addons (or simply using "hg up base" FWIW) BEFORE start working and debugging?
Well, it may have happened due to accident, or laziness, whatever, but the essence is: if you rebase in DVCS-terms, in fact you reduce the dependencies in COI-terms for your addon and should indeed check if it still works without e.g. OrbiterSound, UMMU etc....

Interesting... the more I think of it, the more it seems that all addon-operations can be mapped to DVCS-operations and vice-versa.

regards,
Face

 

[Face]

Working on it a bit more:

The interface comes along nicely (see attachment).
I've decided to not use the tag or bookmark feature of back-end DVCS, but instead create my own text file database inside a nested repository. This way normal DVCS transmission is used for both main repository and addon database (i.e. name of the addon, user, version, short description, link to HTML side, link to embedded PDF, link to embedded readme etc.).

Thanks for all your input so far!

regards,
Face

 

[tblaxland]

For a central repo in the ranks of OH there would still be enough to do. And the web interface itself has to be maintained anyway, since this is only a "headless" infrastructure that can be used by the web interface.

I guess I was wondering what the workload would be for someone like Vash to maintain such a system, relative to the current OH system. That is probably an impossible question to answer, in retrospect.

Indeed. I just don't see COI as replacement for OH, but as infrastructure. It is possible to apply tags to addon-commits in such a way that the tag is a link to a website. On selecting the node in COI's tree-view, a browser-control can display the appropriate link. In addition, another tag can contain a link to the internal documentation of the addon, e.g. a pdf or readme. This can be displayed in appropriate controls, too.
I can imagine various ways to enhance the appearance, but for now I'd like to stay with the plain name for speed's sake.

Makes sense.

OFC, if you are developing a new addon which you know should work based on "base" only, why not update to that environment by deselecting all addons (or simply using "hg up base" FWIW) BEFORE start working and debugging?
Well, it may have happened due to accident, or laziness, whatever, but the essence is: if you rebase in DVCS-terms, in fact you reduce the dependencies in COI-terms for your addon and should indeed check if it still works without e.g. OrbiterSound, UMMU etc....

I often develop in an environment that has more addons in it than my addon has as dependencies. If I am testing out a vessel for example, I might use IMFD in my tests but my vessel does not depend on IMFD. Before I release, I effectively "rebase" anyway - ie, unzip and test the addon on a vanilla install.

Another question: it seems that if I want to host a repo, I don't need to run any special software on the server to do so. The repo is just a bunch of files that is accessed by the clients. Have I understood that correctly?

Client is looking good so far :speakcool:

 

[Face]

Another question: it seems that if I want to host a repo, I don't need to run any special software on the server to do so. The repo is just a bunch of files that is accessed by the clients. Have I understood that correctly?

There are several ways to host a hg repo (via Internet). The easiest one is to use the built-in "hg serve" command. The most complete one is to use a web server with CGI and hgwebdir.
OFC you'd have to open up the appropriate TCP port to the public...

There are several ways for git, too. Unfortunately I'm not familiar with these, I used git primarily local or with GitHub.

For bzr I can't tell you anything beyond Launchpad and Loggerhead.

But for all three one is common: if you have a common file-system via Samba or Windows-SMB, it is just a bunch of files for the clients, so if you've got access to the repository via file-system, you can work with it. So the answer to your question ist: Yes.

regards,
Face

 

[Face]

New progress...

The client is now ready to parse local COIs and display installed and active addons as well as their dependencies.


The meta information about what addon is what revision, user, version and so on is stored in a single database file called ".addons" . Example:

ed509e5d2e03a4da3b36429a53a776842f544e0e;martins;2006 Patch 1;Orbiter 2006 patch 1 - base pack
f237d4323e1224ccf094288ad7951a9ced376ef3;martins;2006 Patch 1;Orbiter 2006 patch 1 - SDK
b2c5cd1a1a1e900c8aca5309627554f971e67fd2;Face;Beta 1;Common Orbiter Installation (COI)
245818192bcbb03ca39651a72519bcaa4c7af609;yagni;1.1;orb:connect
786ee0a8e449bc06384e068c4cd939fbcb4d0af8;martins;Beta;Orbiter Beta - SDK
ea29909e0d4a16a8d2b2636128ecccedd6b6d25a;martins;Beta;Orbiter Beta - base pack

As you can see, there is one line per addon, consisting of the SHA1 content key, the user name, the version string and the name of the addon.

Of course - in order to transfer and manage - the file will be versioned, too. Just not in the main repository - focusing on plain Orbiter installation -, but in a nested repository called "coi". This repository only contains meta-data, therefore there is only one file in it now.


The meta-data points to the SHA1 revision key of the main repo, thus pointing to the exact state the directory should be in when an addon is selected.


As you can see in the log above, the working directory is at revision 10 (the house icon). Therefore, only the packages COI, SDK and Base are active, but not e.g. orb:connect.

So step 1 is taken, step 2 is processing new settings and producing new merges according to activated addons...

regards,
Face

 

[tblaxland]

Looking nice. It sure makes it easy to see dependencies in the COI tree.

 

[Face]

COIClient source code is now available on BitBucket...

 

[Face]

Progress...

The COIClient can now process new selections and update to the appropriate DVCS revision.

1. Plain Orbiter install

o  12[tip]:-1   387b09ff4a02   2009-06-23 19:23 +0200   Face
     test

o    11:9,3   71a0b46778f5   2009-06-23 18:56 +0200   Face
|\     merged alternative
| |
+---o  10:3,9   9a6cf412bd1a   2009-06-23 18:56 +0200   Face
| |/     merged
| |
| o  9   29b6d140e550   2009-06-16 23:25 +0200   Face
| |    Worked a bit more on COI.
| |
| o  8:1   efef654d055e   2009-06-15 23:24 +0200   Face
| |    Added COI client.
| |
| | o  7   786ee0a8e449   2009-06-15 13:36 +0200   Face
| | |    Beta 090520 SDK.
| | |
| | o  6   ea29909e0d4a   2009-06-15 13:35 +0200   Face
| | |    Beta 090520.
| | |
| | o  5   59670252c971   2009-06-15 13:32 +0200   Face
| | |    Added Beta SDK.
| | |
| | o  4:0   2ed3cf016bf6   2009-06-15 13:31 +0200   Face
| | |    Beta 090331.
| | |
o | |  3   245818192bcb   2009-06-15 11:52 +0200   Face
| | |    Update to newest Orb:Connect intermediate version.
| | |
o---+  2:0   d07394a8d48a   2009-06-15 11:51 +0200   Face
  | |    Added Orb:Connect 1.1
 / /
o |  1   f237d4323e12   2009-06-15 12:17 +0200   Face
|/     Added SDK.
|
@  0   ed509e5d2e03   2009-06-15 11:43 +0200   Face
     Added initial Orbiter 2006 Patch 1.

You can see, that the DVCS graph is nowhere near as nice as the flat addon list view. It contains not only additional tree roots (rev. 12), but many intermediate nodes and un"taged" merge nodes.

2. One addon selected
If I now select e.g. the COIClient addon, the SDK is selected automatically, as it is a dependency...

o  12[tip]:-1   387b09ff4a02   2009-06-23 19:23 +0200   Face
     test

o    11:9,3   71a0b46778f5   2009-06-23 18:56 +0200   Face
|\     merged alternative
| |
+---o  10:3,9   9a6cf412bd1a   2009-06-23 18:56 +0200   Face
| |/     merged
| |
| @  9   29b6d140e550   2009-06-16 23:25 +0200   Face
| |    Worked a bit more on COI.
| |
| o  8:1   efef654d055e   2009-06-15 23:24 +0200   Face
| |    Added COI client.
| |
| | o  7   786ee0a8e449   2009-06-15 13:36 +0200   Face
| | |    Beta 090520 SDK.
| | |
| | o  6   ea29909e0d4a   2009-06-15 13:35 +0200   Face
| | |    Beta 090520.
| | |
| | o  5   59670252c971   2009-06-15 13:32 +0200   Face
| | |    Added Beta SDK.
| | |
| | o  4:0   2ed3cf016bf6   2009-06-15 13:31 +0200   Face
| | |    Beta 090331.
| | |
o | |  3   245818192bcb   2009-06-15 11:52 +0200   Face
| | |    Update to newest Orb:Connect intermediate version.
| | |
o---+  2:0   d07394a8d48a   2009-06-15 11:51 +0200   Face
  | |    Added Orb:Connect 1.1
 / /
o |  1   f237d4323e12   2009-06-15 12:17 +0200   Face
|/     Added SDK.
|
o  0   ed509e5d2e03   2009-06-15 11:43 +0200   Face
     Added initial Orbiter 2006 Patch 1.

Notice the "@" sign showing the new selected revision position... it corresponds with the .addons-file entry for the addon in the coi subrepository:

ed509e5d2e03a4da3b36429a53a776842f544e0e;martins;2006 Patch 1;Orbiter 2006 patch 1 - base pack
f237d4323e1224ccf094288ad7951a9ced376ef3;martins;2006 Patch 1;Orbiter 2006 patch 1 - SDK
29b6d140e55053e4995461387c3d8bf17eebb224;Face;Beta 1;Common Orbiter Installation (COI)
245818192bcbb03ca39651a72519bcaa4c7af609;yagni;1.1;orb:connect
786ee0a8e449bc06384e068c4cd939fbcb4d0af8;martins;Beta;Orbiter Beta - SDK
ea29909e0d4a16a8d2b2636128ecccedd6b6d25a;martins;Beta;Orbiter Beta - base pack

3. Two addons selected
Now I select the orb:connect addon additionally. This is equivalent to a merge in DVCS terms. And the system correctly selects a merge revision containing both addons:

o  12[tip]:-1   387b09ff4a02   2009-06-23 19:23 +0200   Face
     test

o    11:9,3   71a0b46778f5   2009-06-23 18:56 +0200   Face
|\     merged alternative
| |
+---@  10:3,9   9a6cf412bd1a   2009-06-23 18:56 +0200   Face
| |/     merged
| |
| o  9   29b6d140e550   2009-06-16 23:25 +0200   Face
| |    Worked a bit more on COI.
| |
| o  8:1   efef654d055e   2009-06-15 23:24 +0200   Face
| |    Added COI client.
| |
| | o  7   786ee0a8e449   2009-06-15 13:36 +0200   Face
| | |    Beta 090520 SDK.
| | |
| | o  6   ea29909e0d4a   2009-06-15 13:35 +0200   Face
| | |    Beta 090520.
| | |
| | o  5   59670252c971   2009-06-15 13:32 +0200   Face
| | |    Added Beta SDK.
| | |
| | o  4:0   2ed3cf016bf6   2009-06-15 13:31 +0200   Face
| | |    Beta 090331.
| | |
o | |  3   245818192bcb   2009-06-15 11:52 +0200   Face
| | |    Update to newest Orb:Connect intermediate version.
| | |
o---+  2:0   d07394a8d48a   2009-06-15 11:51 +0200   Face
  | |    Added Orb:Connect 1.1
 / /
o |  1   f237d4323e12   2009-06-15 12:17 +0200   Face
|/     Added SDK.
|
o  0   ed509e5d2e03   2009-06-15 11:43 +0200   Face
     Added initial Orbiter 2006 Patch 1.

As you can see, there are two merge revisions for the addon combination. This may happen, if you take 2 different approaches to solve a conflict, lets say you rename texture files for conflicting addons differently. ATM, only the first merge is choosen, but this will be enhanced with a selection dialog in the future.

4. Selecting a beta version
I've added the beta version of Orbiter to the repo, too, enabling switching to beta testing by just a few clicks:

o  12[tip]:-1   387b09ff4a02   2009-06-23 19:23 +0200   Face
     test

o    11:9,3   71a0b46778f5   2009-06-23 18:56 +0200   Face
|\     merged alternative
| |
+---o  10:3,9   9a6cf412bd1a   2009-06-23 18:56 +0200   Face
| |/     merged
| |
| o  9   29b6d140e550   2009-06-16 23:25 +0200   Face
| |    Worked a bit more on COI.
| |
| o  8:1   efef654d055e   2009-06-15 23:24 +0200   Face
| |    Added COI client.
| |
| | @  7   786ee0a8e449   2009-06-15 13:36 +0200   Face
| | |    Beta 090520 SDK.
| | |
| | o  6   ea29909e0d4a   2009-06-15 13:35 +0200   Face
| | |    Beta 090520.
| | |
| | o  5   59670252c971   2009-06-15 13:32 +0200   Face
| | |    Added Beta SDK.
| | |
| | o  4:0   2ed3cf016bf6   2009-06-15 13:31 +0200   Face
| | |    Beta 090331.
| | |
o | |  3   245818192bcb   2009-06-15 11:52 +0200   Face
| | |    Update to newest Orb:Connect intermediate version.
| | |
o---+  2:0   d07394a8d48a   2009-06-15 11:51 +0200   Face
  | |    Added Orb:Connect 1.1
 / /
o |  1   f237d4323e12   2009-06-15 12:17 +0200   Face
|/     Added SDK.
|
o  0   ed509e5d2e03   2009-06-15 11:43 +0200   Face
     Added initial Orbiter 2006 Patch 1.

Next is merge revision generation and progress bar...

regards,
Face

 

[Face]

And it goes on...

Merge generation as well as progress and status bar is done. The local side for the first alpha is ready, next step is the remote side (i.e. pulling from remote repos).

If all goes well, we'll have a alpha version ready this weekend.

Brave souls for beta-testing out there? If you're interested, please PM or email me.

regards,
Face