On Thu, Jun 2, 2011 at 7:46 PM, Eric Firing <efir...@hawaii.edu> wrote: > On 06/02/2011 12:35 PM, Darren Dale wrote: >> On Thu, Jun 2, 2011 at 6:07 PM, Eric Firing<efir...@hawaii.edu> wrote: >>> Going forward, is there any good reason to retain all the old branches >>> (transforms, 0.91.x etc.)? >> >> I don't think we need the transforms branch. I kept it just for the >> sake of completeness during the svn->git migration. >> >>> Don't the release tags provide adequate >>> access to those branches? My sense is that merging them into master was >>> not good from the standpoint of being able to read the graph and see >>> what is really derived from what; but I don't know exactly what can be >>> done about it. They certainly clutter up the output of "git branch -a" >>> to no useful effect. >> > >> There was actually a good reason for doing it this way. Each older > > I understand the rationale, but... > >> maintenance branch was merged into the next newer one, and it was done >> with --strategy=ours (which basically means that any changes were >> ignored during the merge). We did this so that if someone applied a > > which means that it is a fundamentally misleading merge--a merge in name > only, not an indicator of what is in a given branch.
No, it meant that all of the actual merges that we intended to do had already been done using svnmerge. But svn2git wasn't able to capture all of those relationships, so instead we did what we could at the time of the conversion. >> critical set of patches to an earlier maintenance branch, say 0.99.x, >> and wanted to merge it into v1.0.x, and then into master, it would be >> easy to do so without unintentionally pulling all of the other changes >> between 0.99.x and 1.0.x (for example) along with it. > > I think the likelihood of anyone ever actually doing this is near zilch; > we don't maintain old branches. aside from 1.0.x... > And for the single current maintenance > branch at any given time, cherry-picking bug fixes from maintenance to > master or the reverse seems to me more explicit, less mysterious, and > less likely to have unintended consequences than merging. I understand your position. >> >>> Following along this line, does it perhaps make sense in the future to >>> use cherry-picking instead of merging for propagating bug fixes between >>> a maintenance or release branch and master? My uneducated sense is that >>> it would leave a less confusing graph, and be less likely to result in >>> errors. >> >> I would prefer to continue merging. I think its just a matter of >> getting in the habit of inspecting the history graph. But that's just >> my opinion. > > I still don't agree. It looks to me like numpy is using the cherry-pick > approach, not the merge approach, and the result is that each branch has > a reasonably linear history that one can actually follow by eye, and > easily see exactly what has been done. Compare numpy: > > http://currents.soest.hawaii.edu/hgstage/numpy_from_git/graph/9264?revcount=240 > > to mpl: > > http://currents.soest.hawaii.edu/hgstage/mpl_from_git/graph/6855?revcount=240 Numpy appears to be applying all of their changes on master, and then cherry picking changes to apply to the maintenance branch. > Even without the foulup, I think you would see that the merges from > maintenance branches into subsequent branches and into master make it > very hard to figure out what has actually been done on any given branch. I strongly disagree. The only reason you get cleaner history graphs with cherry picking is because it doesn't graph the cherry picks! If you want to know what has been merged, you have to inspect the commit message in one branch and match it up with the commit message in another branch. How does that make it easier to figure out what has been done on any given branch? > Undoubtedly one *can* figure it out, as apparently you have just done; > but it is not immediately clear from the graph. I have another suggestion, relating to somebody's (your?) suggestion that we make more frequent releases. Development would be more robust if we were all branching from a commonly acknowledged reference point. For example, that might be v1.0.1 on the maintenance branch. The history graph would probably be cleaner as well. Then when a branch X is merged into maint, maybe we should be merging branch X into master as well, rather than merging v1.0.x into master. That would make it clearer what was actually being merged. Then, when v1.0.2 was tagged, we merge that into master (perhaps with strategy=ours if appropriate), and that becomes the new commonly acknowledged reference point on the master branch. Darren ------------------------------------------------------------------------------ Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Discover what all the cheering's about. Get your free trial download today. http://p.sf.net/sfu/quest-dev2dev2 _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
