On Tue, May 27, 2014 at 11:12 PM, Johan Brichau <johan@inceptive.be> wrote:
On 27 May 2014, at 22:09, phil@highoctane.be wrote:
Ok, will have a look.
At first sight, it looks scary and less friendly than a plain old MCZ merge.
But... git is the standard and it is painful to have to maintain things in two places...
I'm testing the 'git for smalltalk' workflow in the context of our team because we really want the flexible branching which is non existent in MC. If you want to have continuous release, a single trunk repository is not cutting it. Git is good at that and the availability of things like github/travis/pull requests etc... is also a big plus, although it certainly is a lot more complex than mcz.
Agreed. We are using GitLab and it rocks! Add to that that a chunk of the application has nothing to do with Smalltalk and is using Bash, Php, and whatnot to get the things done. Git is also great to deploy the stuff on multiple machines.
The GitFiletree mergedriver takes away a lot of the burden when working with the filetree format. It is a big step forward but imho it will only be truly used when git is integrated with the Smalltalk IDE for real.
It works well once you get the hang of it but there are many manual things to take care of, which is why I'm still reluctant to introduce it fully in our development flow because making mistakes can easily lead to lost code, wrong version history, wrong merges, etc...
Yes, at the moment we save to filetree:// to have a trace in git but the real merge work happens in a MC Repo (FTP w/ user&password), which works nicely enough.
So, for now, we use it for experimental branches and we do a manual merge back into a monticello repository when it needs to go into production.
De l'expérimentation quoi.. ;-)
I am with you on that. Git is complicated enough without embarking of weird scenarios like that. But for teamwork, this is invaluable. Phil
Johan