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
Monticello: Workflow for simultaneous collaborative development / correctly numbering a version when copying to remote repository
-
25-09-2022 - |
質問
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 isFamousSmalltalkGuy.14
. - I commit in the morning (15), at lunch (16), and in the evening (17) locally. Now package
Foo
locally is up toDanielLyons.17
. - Looks like Famous Smalltalk Guy pushed version 15 to Smalltalkhub.
- I merge
FamousSmalltalkGuy.15
with what I have in my image, producingDanielLyons.18
.
Now I want to push DanielLyons.18
up to Smalltalkhub. What's the right thing to do?
Copy the version (clicking the Copy button in the Monticello UI).
This feels wrong because there will be a discontinuity from
FamousSmalltalkGuy.15
andDanielLyons.18
.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!
解決
他のヒント
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:
- Fetch the current version, say
Foo-FamousSmalltalkGuy.14
- Do your stuff and commit it like:
- Commit your version
Foo-myImportantTopic-DanielLyons.15
- Commit your version
Foo-myImportantTopic-DanielLyons.16
- Commit your version
Foo-myImportantTopic-DanielLyons.17
- Commit your version
- Adopt as Ancestor the version
Foo-FamousSmalltalkGuy.14
- Commit to the remote as
Foo-DanielLyons.15