Search code examples
version-controlsmalltalkpharomonticello

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


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!


Solution

  • 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