Monticello: Workflow for simultaneous collaborative development / correctly numbering a version when copying to remote repository

Question

While working, I make lots of revisions. Whenever the code is in reasonable shape, I like to commit. But not all of those commits are interesting. So I make these commits to the local disk or a private server. It looks something like this:

• I fetched package Foo in the morning, so it's version is FamousSmalltalkGuy.14.
• I commit in the morning (15), at lunch (16), and in the evening (17) locally. Now package Foo locally is up to DanielLyons.17.
• Looks like Famous Smalltalk Guy pushed version 15 to Smalltalkhub.
• I merge FamousSmalltalkGuy.15 with what I have in my image, producing DanielLyons.18.

Now I want to push DanielLyons.18 up to Smalltalkhub. What's the right thing to do?

1. Copy the version (clicking the Copy button in the Monticello UI).

   This feels wrong because there will be a discontinuity from FamousSmalltalkGuy.15 and DanielLyons.18.

2. Commit a new version in the Smalltalkhub repository, manually writing DanielLyons.15 in the box.

   This feels wrong, because it seems to confuse my local image. After all, it's seen a DanielLyons.15 before, and this isn't it.

I feel sure that there's a right thing to do here, but I don't know what it is. If anyone can shed some light on the right Monticello workflow for simultaneous collaborative development, I'd greatly appreciate it. Thanks!

Answer 1

You should copy all your versions to remote repository, otherwise you will loose valuable history. Curently because of how Monticello is implemented it produces a lot of broken links to ancestors, as people forget to copy intermediate versions from their local storage. And yes, version numbers are stupid. You cannot have sequential version numbers in distributed versioning, so I prefer to leave commit names as they are and just copy everything to the remote repository

Answer 2

Backport

Monticello has a so-called backport changes feature, that lets you apply changes you accumulated over several commits plant onto an older version. It is seldom used, tho.

Branch

Another process would be to locally make a branch and only at the end make a merge with the version you want to commit on.

A Monticello branch is done by appending -branchname to the package name: Foo-DanielLyons.18 becomes Foo-mybranch-DanielLyons.18

If Monticello refuses to merge, you can say “adopt as ancestor” and specify, that your new version has both your branch and the original commit as ancestors.

The process then goes like this:

1. Fetch the current version, say Foo-FamousSmalltalkGuy.14
2. Do your stuff and commit it like:
   1. Commit your version Foo-myImportantTopic-DanielLyons.15
   2. Commit your version Foo-myImportantTopic-DanielLyons.16
   3. Commit your version Foo-myImportantTopic-DanielLyons.17
3. Adopt as Ancestor the version Foo-FamousSmalltalkGuy.14
4. Commit to the remote as Foo-DanielLyons.15