Agree, with both Andreas ( need more advanced branching policy ) & Guilaume ( need to -re-read) ;)
One of the side effects that i was just looking in are much more trivial and related to maven-release-plugin i guess: I noticed during pax exam 1.2.3 release process that stuff is pushed automatically on the remote side, which i actually don't want. Any simple hint of archiving this ? Toni On Thu, Nov 25, 2010 at 11:19 AM, Guillaume Nodet <[email protected]> wrote: > On Wed, Nov 17, 2010 at 03:59, Andreas Pieber <[email protected]> wrote: >> Hey guys, >> >> I've seen that there are no tags of the current releases at pax-web. >> @Guillaume >> you may like to push them too? (git push --tags) > > Done > >> >> BTW @Release-Branches and Maven (paxweb-0.7.x). Thre is some quirks between >> the >> way the maven release plugin and git works with this classical svn model... >> (This is some git-problem now; I hope I can keep it simple; please ask if not >> :)). >> >> Ok lets start: There are two possible workflows with git and support (AFAIK) >> (these >> branches with the x in the version number; e.g. paxweb-0.7.x) branches: >> >> a) commit changes on support branch OR master and cherry-pick them to the >> other >> side. >> >> (+) no pain, simply pick required commits >> (-) loosing history between fix on master and fix on support branch (a cherry >> pick creates a NEW commit (new parents and childs --> new sha1 --> new >> commit)) >> (-) cherry-picks with "more" commits are either painful often execution of >> cherry-pick or quite complex git-rebase actions >> >> b) either change directly support branch and merge it into master (or >> better) branch off support branch and merge into master and support. >> >> (+) history is kept >> (+) very easy to handle >> (-) many merge nodes >> >> BUT using (b) there's a serious problem now with the way git (and the >> mvn-release-plugin) works. (1) you really have to start chagnes you want to >> have >> in the master based on the support branch; otherwise the "back-merge" will >> also >> include all other commits done in the master; and I'm sure we do not want >> that. >> (2) if we directly do the work in the support branch and merge this one back >> to >> the master you (2a) also add all other changes you've done to the support >> branch >> (ok, this is typically not so bad because it only reflects that there should >> be >> no infrastructural changes in support branches anyway) BUT (2b) you also >> apply >> the changes in the pom files (and this is a real pain). I hope that the >> second >> problem is clear. You apply the commits version increased, version back to >> snapshot commits which are afterwards merged into the master and change the >> version there too. At openengsb.org (for example) we solve this problem now >> by >> using a support-dev and support-release branch. The support-release branch is >> not merged back into the support-dev branch and the releases of the >> support-branch are done by mergeing the support-dev branch into the >> support-release branch and doing the release there. The work is going on in >> support-dev till the next release where we merge support-dev again into >> support-release (you may like to take a look at [1] to see what I'm talking >> about). >> >> In a nutshell: model (a) is easier but really has some quirckses about the >> history (IMHO) and can become quite unlogical in the git-way-of-doing things. >> Model (b) requeires much more discipline by developers but produces (IMHO) >> the >> better outputs in history graphs and understanding the history of a project. >> >> Sorry for the long post, but I really thing we should discuss this :) > > I guess I need to re-read it ... I'm not very used to pure git dev yet ... > >> >> kind regards, >> andreas >> >> [1] https://github.com/openengsb/openengsb/network >> >> >> _______________________________________________ >> general mailing list >> [email protected] >> http://lists.ops4j.org/mailman/listinfo/general >> >> > > > > -- > Cheers, > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > ------------------------ > Open Source SOA > http://fusesource.com > > _______________________________________________ > general mailing list > [email protected] > http://lists.ops4j.org/mailman/listinfo/general > -- Toni Menzel || http://okidokiteam.com _______________________________________________ general mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/general
