geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <ja...@planet57.com>
Subject Re: [jira] Commented: (GERONIMO-2161) [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml
Date Thu, 06 Jul 2006 20:50:37 GMT
On Jul 6, 2006, at 12:36 PM, Jacek Laskowski wrote:
> On 7/6/06, Jason Dillon <jason@planet57.com> 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

Mime
View raw message