Btw; this simplifies the overall workflow to: "Check out the oldest version you want to support this feature and add your IT + change there. It may still be a good idea to do IT and core-change as two different commits"
Kristian 2012/10/12 Kristian Rosenvold <[email protected]> > I could not resist, I made this repo and it works well: git clone > https://github.com/krosenvold/maven-rc.git > > It has reconstructed mergeability between 2.2.1 and 3.X, and the IT's were > added at 2.2.1 and merged up to 3.X. Which means we have a straight merge > based workflow from 2.2.1 and on. Pre 2.2.1 versions are not supported for > this mode of operation. > > Note: Older tags (pre. 2.2.0) will have to be reconstructed by hand once > we flip. Also; the pom.xml and the site in this merged repo contain only > the "core" pom (changes from core-its pom.xml and site will have to be > merged by hand) > > Btw: In this repo, you can checkout trunk (3.X and do "git diff ...2.2.X" > and see what changes have been added to 2.2.X. Note three ...'s) > > Kristian > > > 2012/10/12 Kristian Rosenvold <[email protected]> > >> NIce use case, this is where things get interesting ;) Initially I'll >> just add that this is one of those workflows that might be easier with a >> separate IT repo. This is how the flow would be in a merged single repo: >> >> This workflow has two distinct modes of operation: >> >> 1. You always check out the oldest appropriate branch to make the IT. So >> if the IT should apply to 2.2.1 you should check that out. (If we need to >> make IT's that go even further back I think it might be easiest to just >> keep the IT's in a separate repo since it gets really hard to actually >> *make* that repo.) >> >> 2 A) You are working in a "properly" branched structure that is mergeable >> ; i.e. what we might do between 3.0.X and 3.1 or maybe more appropriately >> between 3.X and 4.X. >> >> Make all the changes your heart desires, in any kind of commit sequence >> you prefer. The downstream merge to the subsequent version will fix it all. >> >> 2 B) You are working i an unmergable branch structure (2.2.1->3.0) >> >> Add the IT as a distinct commit on the 2.2.1 branch, make sure any >> bug-fix you do is done as a separate commit from the IT. When done, you >> will need to check out the 3.0.X branch and cherry pick the commit with the >> IT. From 3.0.X on it will merge properly. cherry-picking is a manual >> operation and if you forget it, the IT will be "lost" on 2.2.1 >> >> While this all may seem a bit complex, it's basically the nuts & bolts of >> how day-to-day life of a branched workflow functions. When working in older >> history, it's usually wise to partition work into well-defined commits, >> because sometimes you might end up cherry-picking only parts of the work >> forward. When you're on trunk you usually don't need to worry about this >> stuff. >> >> {begin Theoretical Technical digression for the git-savy} >> Theoretically we should be able to make a single "phoney" merge commit >> that re-establishes the mergeability between the 2.2.1 and 3.0.X branch so >> that any subsequent changes we make to 2.2.1 can merge directly downstream. >> I have not done this in practice but I'm sure some others here have. I'm >> thinking something like this: >> git checkout maven3.0.X >> git merge -s ours origin/maven-2.2.1 >> >> Now of course I want to test this out before we proceed >> {end Theoretical Technical digression for the git-savy} >> >> >> Kristian >> >> >> 2012/10/11 Jason van Zyl <[email protected]> >> >>> Say I have the following scenario: >>> >>> I'm working 3.1-S and creating some new ITs, and then I work on 2.2.x >>> and create some ITs. What's the plan with making sure that we have one >>> cohesive set of ITs that we can use across all versions? Just merge >>> additions back into every branch? Because we would need to checkout two >>> copies in order to be at one branch for the version of Maven you're working >>> on and the branch where the ITs are. I understand wanting a rationalized >>> fork and with unit tests I understand, but did you forks of large OSS >>> projects include ITs like this? >>> >>> If that workflow is sorted out it seems fine. I just don't want it to be >>> onerous to achieve the discipline of having on coherent set of tests that >>> work across all versions of Maven. It's pretty easy to make that consistent >>> right now. There's not a huge number of branches so merging additions back >>> to each branch is pretty easy. Is that what you had in mind? >>> >>> >>> On Oct 11, 2012, at 4:06 PM, Kristian Rosenvold < >>> [email protected]> wrote: >>> >>> > 2012/10/11 Arnaud Héritier <[email protected]> >>> > >>> >> Now let's say that someone wants to solve a problem on a maintenance >>> branch >>> >> (thus not master) >>> >> With git it will checkout this branch to work on the fix, but if in >>> // he >>> >> wants to add an IT it will add it on this branch (not on master where >>> we >>> >> should have all ITs ?) >>> >> How many chance that one day we forgot to merge back ITs from all >>> branches >>> >> in master ? >>> >> >>> > >>> > If you make any kind of change on a branch (bugfix/feature/whatever) I >>> > would >>> > expect to have test updates being done on that branch too, so the >>> branch >>> > represents a complete "diff" of the change; both feature and tests. >>> > >>> > When the fix/feature is merged back into master the tests come along, >>> if >>> > the feature is >>> > never merged to master, the tests stay in their branch - just like they >>> > should. >>> > >>> > This is a healthy mode of operation; if you look at the branches in my >>> > surefire github repo >>> > (https://github.com/krosenvold/maven-surefire) I have like 15 >>> different >>> > branches. >>> > Some of them are specific JIRAs and may contain testcases and partial >>> > fixes. Now I will >>> > start pushing these to the ASF git repo instead, since they represent >>> work >>> > on an issue >>> > that is not fully fixed; maybe just a testcase or a test project. >>> > >>> > I think it's important we acknowledge the existence/intention of such >>> > branches on >>> > the corresponding JIRA when we make such feature branches in the >>> official >>> > repo. >>> > If I just push it to my personal github repo it can be as messy as I >>> > prefer, but when >>> > I push it to ASF I'd prefer it to have reasonably well-defined >>> > responsibility (like test-case, >>> > suggested fix or similar) and some value to others. If it's just my >>> > personal doodles I'll >>> > keep them in my personal github. >>> > >>> > As for branches that never get merged back; well that's life and >>> usually >>> > there's a story >>> > behind that and we tell it in jira. >>> > >>> > Kristian >>> >>> Thanks, >>> >>> Jason >>> >>> ---------------------------------------------------------- >>> Jason van Zyl >>> Founder & CTO, Sonatype >>> Founder, Apache Maven >>> http://twitter.com/jvanzyl >>> --------------------------------------------------------- >>> >>> In short, man creates for himself a new religion of a rational >>> and technical order to justify his work and to be justified in it. >>> >>> -- Jacques Ellul, The Technological Society >>> >>> >>> >>> >>> >>> >> >
