26 марта 2012 г. 4:30 пользователь Stas Malyshev <smalys...@sugarcrm.com> написал: > Hi! > >> Main problem is that our current workflow doesn't allow branch-only >> changes. I.e. if you make a bugfix and want to stay it in PHP-5.3 only >> you can't merge 5.3 with 5.4 anymore, otherwise your bugfix will go >> there. > > Why would you want a bugfix to be in 5.3 but not in 5.4? Can you give an > example? > I can see it if the code had substantial change there so bugfix no > longer applies. In this case, I would try the merge, see it fail and > resolve it as "all ours". It shouldn't take longer than 10 mins. Though > it you have ideas how to improve that without disrupting the rest of the > process and the common use case, you are welcome.
For example this commit http://git.php.net/?p=php-src.git;a=commit;h=8d0760f38a9d3dabb3a31d1d47f85827d27d0db4 by Ilia was intentionally commited in PHP-5.3 only, maybe Ilia will describe better. It was then accidentally merged into PHP-5.4 by Hannes (which broke something in PHP-5.4) when he was merging his own changes which merge made a lot of confusion. We should really deal with this problem first before diving further, since it will have great impact on the whole working process with git. If we can live with simple git merge - it would be simply awesome. >> 1) use cherry-picking in one repo. This has big downside (as dsp >> pointed) that we can't use git annotate, bisect and other commands >> assuming that commit is introduced in repository only once. > > bisect is a bit weird now btw, since it seems to be a bit confused by > 5.3-5.4 merge that happened not when it thinks it did - so if you try to > bisect changes in 5.4 branch only, you will get some very old changes > in. You can quickly go through that, marking them as good, but still not > ideal situation. Yep, already tried bisect and it doesn't seem work good at least for php-5.3 branch. >> Okay, since I'm not too familiar with release process, assume >> following (please, correct me if I'm wrong): >> * PHP 5.3 can't have features, only bugfixes > > True. > >> * PHP 5.3 can have bugfixes that are merged upstream (PHP-5.4 and >> master) and bugfixes that should stay only in PHP-5.3 > > Not entirely true - 5.3 code can have bugfixes that aren't merged up, > but that would not be the common case. Example - bugfix regarding magic > quotes or safe mode, which are not in 5.4. So it's still possible to have not-merged up bugfixes. That means that we should take that into account. I'm just trying to figure out our needs to better understand what needs to be done then. > >> * PHP-5.4 and master can have bugfixes and features that are merged >> upstream (master) and bugfixes/features that should stay only in >> current branch > > 5.4-only fixes very unlikely, as master and 5.4 are very close today. If > we ever do big changes in master this is a possibility, as described > above, but still won't be a common case - unless we rewrite our engine > completely, which doesn't seem to be likely. > >> * All branches are have regular releases > > True, except for master. > >> In gitflow you have 4 branches: >> * master - contains only production ready releases, nobody commits here >> directly >> * develop - main development branch, all work usually is get merged here >> * feature/<name> - feature/bugfix branches for separate bugfixes and >> features. Merged into develop. >> * hotfix/<name> - same that feature branches but is urgent and is >> always merged into master *and* develop. For example, when security >> release is issued, this fix should go into release and into main >> development branch. >> * release/<name> - pre-release stability branches, for bug-fixes only. >> Merged into develop and master (making a new release). When you have a >> release branch, you can't commit into develop (so hotfixes go here >> too, if we have release branch). > > I don't like that "can't commit into" thing - the main advantage of git > as I see it that you can manage release branch and dev/stable branches > separately and not have the situation of asking people to sit on their > code for 2 months while release is being stabilized. Sorry, I messed this up. You actually can commit into the develop, new features go there, while bugfixes should go in release branch. If you want you can merge release branch into develop anytime you want, it's just should be done at least once when release branch is closed. >> Make a bugfix in 5.3 >> $ git flow feature start bugfix PHP-5.3 # create a bugfix branch based on 5.3 >> $ git flow feature finish -k bugfix 5.3-develop >> Bugfix get merged into 5.3-develop - this should be implemented since >> gitflow supports only 1 develop branch for now. -k says to keep branch >> after finish, since we'll need it to merge upstream > > Why would we need bugfix branch in our repo here? I would say keep it in > your own fork, test it, show it off, get it ready - then merge it into > php repo. What is the reason for us to keep halfbaked fix branches in > our repo? > >> Merge bugfix from 5.3 repo to 5.4 >> First, rebase branch against 5.4 >> $ git rebase --onto develop-5.4 bugfix~<num> bugfix >> Where <num> is number of commits in your branch. I know it sucks, but >> that's how it works :) > > I don't like it. Too fragile and too easy to mess up. > > In general, this scheme seems quite complex and I don't really see what > the benefit of it would be. Could you explain why would we want to do this? Canonical gitflow is very straightforward and clean. Here it seems complex because I tried to apply it on the fly to PHP needs. PHP adds complexity because we support several release branches at once, while in gitflow there's only one release branch in the given moment of time. That's why my first thought was to divide our release branches in separate repos, this way we could start use gitflow in its current state. Advantages: * clean separation of release branches, main development and hotfix branches * if you use git-flow tool you don't have to remember what branch should you start your feature/bugfix, where to merge when it's ready, it's all already thought through and automated, that's really cool especially when you make a release I strongly recommend you to read original article http://nvie.com/posts/a-successful-git-branching-model/ and spend half an hour on this hands-on tutorial http://vimeo.com/16018419, so you can really feel how it works. No doubt that we can't use gitflow as-is, i.e. we would need to modify it to suit our needs, but it can realy simplify our life. Disadvantages: * Cli oriented toolbox. As Matthew pointed out you can't use git-flow with git GUI tools and support on Windows seems not so good * Written in bash. There was attempt to rewrite it into python, but it seems things stopped there about year ago: https://github.com/nvie/gitflow/tree/feature/python-rewrite * Some time (not much) is needed to understand the system -- Regards, Shein Alexey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
