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 <kristian.rosenv...@gmail.com>
> 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 <ja...@tesla.io>
>
>> 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 <
>> kristian.rosenv...@gmail.com> wrote:
>>
>> > 2012/10/11 Arnaud Héritier <aherit...@gmail.com>
>> >
>> >> 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
>>
>>
>>
>>
>>
>>
>
