On Jul 6, 2006, at 12:36 PM, Jacek Laskowski wrote:
On 7/6/06, Jason Dillon <[EMAIL PROTECTED]> wrote:
The exact command used to make the v5 patch was (from trunk):
svn diff > GERONIMO-2161.patch
And, as I thought I explained to you before, the same changes are
applied to this branch:
https://svn.apache.org/repos/asf/geronimo/sandbox/svkmerge/
m2migration/
You can just use the branch to test the changes, or merge those
changes into your branch, which should have the same results at the
cost of additional merging.
You've been working on the patch in your local copy of Geronimo trunk.
You did svn co ...trunk. Correct? When you finished your work, you
executed 'svn diff' to cut the patch. Correct? The patch turned out to
be 'broken' or 'incompatible' for unix patch command and thus noone
could test it out extensively, but look at it and verify reading.
Correct?
Mostly correct. You could apply the patch and examine the failed
chunks and notice the trivial changes and how they would not alter
the change and test w/a high degree of certainty that the changes in
the patch were and are valid.
But... due to the problem with svn diff+patch it made it much harder
for folks to review and produce positive votes, due to the added
overhead of the work and understanding of the failed patch chunks.
1/ You're working alone with no help from anyone. No, I don't mind
your working alone and show changes when they're ready. The point is
that I don't foster an interest of others to be involved and possibly
contribute/help you.
Again mostly correct. I had been working with David, Prasad and
others as they applied the patch and then took feedback, fixed issues
and then re-crafted patches. So, I was not working alone in that
sense. But others could not directly help me work by submitting code
to the codebase as would have been the case if we were all working
and committing to SVN.
For me this was a stretch, because I generally like to commit as
often as possible when new features or fixes are introduced that are
compatible with the build. I like to use source control to help me
manage what changes I am making.
2/ As we have already found out, unix patch is not reliable and thus
is not an option in a long turn. We need to figure out a way to work
in a collaborative manner without the overhead of unix patch that
makes the process of applying changes more complicated than it really
needs to be. If your changes are between some revisions (e.g. initial
branch creation revision and HEAD) anyone can use the branch and apply
the change with svn merge command to his/her local Geronimo sources
copy and test it out. Once an issue is found, the one who spot it
could fix it in your branch and again call a vote.
We MUST understand and resolve why svn diff + patch is broken, or why
it could break. We MUST figure this out... regardless of whether the
ongoing RTC work is done on a branch.
But, we also need to find a way to allow more collaborative work to
be done while following the RTC rules for commits to trunk.
I believe that using branches works for this... in theory... BUT
since merging in SVN is not as automated as it could be (or should
be), that we must be-careful not introduce more overhead from merging
and conflict resolution, which if not done carefully could be more
harmful than good.
This is why I was looking into SVK, since it provides another level
on top of SVN with a more intelligent merging algorithm and
integrated conflict resolution in a very Perforce-style (which IMO is
highly effective).
There're some other benefits, but these should be enough for now
(unless you're not convinced and I'll have to write them down ;-))
Don't get me wrong... I think that using branches is a good idea. I
just wish that SVN was better at facilitating the merge back. And
since it is not, we must be very careful not to over-branch in set
ourselves up for insane merges.
* * *
I still do believe that for the m2 build system implementation, that
a branch is not needed, the work could (and should) be done on the
trunk. Once finished, we can call a RTC vote on if the m2 build
should be the default and at that time begin the work to remove the
trails left over to support the m1 build.
There is still a bunch of work left, and some of it will involve
moving modules around into more sensible hierarchies. We are going
to want to make these changes on the trunk... the added overhead of
managing a merge from branches post-reorg w/SVN is going to be way,
way to high.
But, just to note... before any such work is done the general ideas
will be presented for the community to vote upon. This is what I had
intended the initial GERONIMO-2161 RTC to be used for. To vote on
the concept and then implement on trunk. but, due to the slowness of
the RTC process the work progressed faster than people could react to
the RTC and soon the RTC issue became a set of patches and not just a
concept.
To be clear, I think that some of the concepts of RTC are very
positive. But, I think that some of the rules around its application
need to be augmented to be more flexible and thus more effective.
--jason
