Re:Trunk-Based Development
by chrisseaton on Sunday January 29, 2017 @07:38PM
(#13517785)
How does a team of Smalltalk developers work? How do you merge the binary Smalltalk program image?
Re:Trunk-Based Development
by stcredzero on Monday January 30, 2017 @03:18AM
(#13519428)
Most places I worked "built" by loading the release configuration, then saving off the image. That's often all there is to it. At one job, some pre-population scripts were also run for menus and drop downs.
With time, Smalltalk also got its own version control tooling.
Monticello for example,
Re:Trunk-Based Development
by stcredzero on Monday January 30, 2017 @10:43AM
(#13522049)
You could consider Monticello as one of the precursors of git.
If a check in breaks the build or breaks production on deployment, it should be rolled back within minutes. Trunk and production must always be healthy, and if you commit poorly tested code, you are doing nobody any favors.
It was a badly run organization - and, as an extension, bad management, bad developers, bad process, bad requirements and bad practices. It wasn't trunk-only that made the project grind to a screeching halt - it was people.
My background in Smalltalk made me accustomed to a style where everyone would continuously merge everyone else's changes as they worked. This style makes you aware of what your team mates are doing. In fact, it facilitates communication pretty much when communication is most called for.
As always: context. The above approach is only going to work well, when there is convenient high bandwidth communications between teammates. (Not only for your version control, but also for communication between people.)
I've seen trunk-only developers not knowing how to merge a branch back to trunk.
Well of course. If they never had constant practice at merging, they wouldn't be very good at it. Merging isn't trivial.
I've seen trunks brought into a state of disarray and never fixed again.
Can't they roll back? This strikes me as a sign of badly designed process, or developer incompetence. This should be seen as something like breaking the build. (In a CI environment, it would be breaking the build, yes?)