[squeak-dev] Re: The Trunk: Monticello-ar.379.mcz

Colin Putney cputney at wiresong.ca
Thu Mar 11 03:34:56 UTC 2010

On 2010-03-10, at 5:51 PM, Andreas Raab wrote:

>> No. It's always better to commit first and merge afterward. If you have a collaboration style where the "head" is an important concept, you just merge right after committing, rather than at "integration time."
> It's interesting to see the different styles at work. For me, having the notifier makes the overall workflow much more efficient. Take trunk for example (our internal workflow is very similar): If you get a reminder that there's something "ahead" of your commit, you hit update and it's done in about ten seconds or so. Conflicts are rare so there mostly isn't anything else to do.
> Contrast this with the alternative: It implies that for *every* commit you need to check the repository if there is a potential conflict (this is why I said "I'm too lazy" in the checkin comment). If there is, you need to select the unmerged version(s), merge them, write a change comment, save them back. Repeat that for every commit. After a while you're so tired out that you don't check and it goes okay, until you get really bitten. That's the point when you start wondering why MC can't tell you that there's stuff you need to merge. At least that's the way it worked for me :-)
> BTW, like I said earlier, I'll be happy to make that a preference. Different people work differently, no need to slow you down with something that serves no purpose in your chosen workflow.

Well, if you really must have such a check, then yes, please make it a preference. 

But I think we're talking past each other. It really is better, from a package-history point of view, to commit regardless of what else is in the repository, and merge afterward. If the UI makes that too difficult, fine, let's fix *that* problem.

What about a preference that automatically merges after a commit? It would go something like this:

- you click save, type a log message, click accept.
- MC saves a new version of the package, as usual.
- If the preference is set, it checks the repository for unmerged versions. For each one it finds:
	- MC does an update, merging that version into your image
		- if there are conflicts, you get a dialog, otherwise it's silent
		- MC saves the merged version back to the repository, with an automatically generated commit message


More information about the Squeak-dev mailing list