Although I understand we can make the merged repository work, at least
with some discipline from developers, I think merged source repository
makes changes to the integration tests perceptually "okay", which imho
is rarely the case. I actually maintained fork of maven ITs for
awhile, and personally I did not find it too much trouble. At least as
long as I was only adding new ITs, not changing existing ones.
Just my 2c.
--
Regards,
Igor
On 12-10-12 3:47 AM, Kristian Rosenvold wrote:
My mails came out sort-of in the wrong order, and I'm not sure if I agree
with myself on splitting it changes <-> core changes.
There is no technical mandate for this, not even a practical one since
establishing mergeability from 2.2.1 -> 3.X turned out to be simple.
But as a personal work habit it's smart, because it allows you to change
your mind easily.
Let's say I want to fix MNG-9999 on 3.X. I make an IT from a submitted
sample project and I commit that on the 3.X branch.
Now someone really wants that fixed back on 2.2.1, and it turns out the
backport is real simple. All they need to do is cherry pick the IT and the
core change back to 2.2.1. The IT always cherry-picks cleanly (more or less
by definition due to the way we make IT's), but the core change does not,
so the fix had to be re-applied on 2.2.1. When we merge 2.2.1 back to 3.X,
git will automatically understand that the cherry-picked IT exists "in the
future" and it won't trouble me with it. If the core change had been part
of the IT commit I would lose this benefit, since the diffs become
different (lol).
(A diff that already exists in the history won't be reapplied, which is why
it's so good to move *complete* commits backwards in time).
Kristian
2012/10/12 Arnaud Héritier <aherit...@gmail.com>
"It may still be a good idea to do IT and core-change as two different
commits"
If we merge core and ITs I think it will be important to do it (and thus to
ask it to contributors - or we'll need to do it on our side).
I always see few reasons to merge them and find the process a little bit
complex (especially if the committer isn't a Git Guru) but I admit that I
won't bit impacted by this choice as my core contributions were (and will
probably continue to be) near to nothing.
Even if I really support the Git migration I don't want that we decrease
the ability to contribute (it is already a big issue)
Arnaud
On Fri, Oct 12, 2012 at 8:34 AM, Kristian Rosenvold <
kristian.rosenv...@gmail.com> wrote:
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 <kristian.rosenv...@gmail.com>
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
--
-----
Arnaud Héritier
06-89-76-64-24
http://aheritier.net
Mail/GTalk: aherit...@gmail.com
Twitter/Skype : aheritier
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
