Dear Urs,
I think what Colin meant by "build token" is another strategy to archieve
the same as what I described with "checkin/merge to the main branch" and
"personal development branches". I think he has in mind a decentralized
version control tool, where you first work with your local version,
commiting changes to this local version (as I, using subversion/SVN, would
have done with a personal branch). Then, when he has the "build token",
he first updates his local version with the official changes, debugs his
changes until they are in a working state, and then publishes his changes.
He makes sure that the published version is up to standard, so no coworker
has to debug his stuff. In case he finds his changes make bigger fuss than
he thought, he can always give back the "build token" without making any of
his changes public (that means he reverts to the previous working thing).
Then he does local work again, and when he trusts this time he will be able
to make everything work, he again acquires the "build token" to make them
public.
So, if I understand him correctly, the strategy is the same, just the
technology used and their abilities differ.
Hope that helps,
Susan
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
