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
>
>
>
>
>
>
