Yes, I agree that the person committing knows best what should go into
1.0.X and 1.2.X. The ubermerge process is very error-prone.
Scott O'Bryan wrote:
Jeanne,
Yes they are saying different things but the two are not mutually
exclusive. What I was saying was +1 to creating a 1.2 trunk.
That said, we will have to move to a situation where patches are applied
to the main branch as a per-patch basis to make this manageable. Matt's
concerns for creating this trunk are valid and can be addressed quite
easily by changing how we choose to apply changes. I think in the long
run it'll make the 1.2 branch more stable because we will no longer have
to depend on an UBERMERGE to get the code into the new branch. Instead
issues can be addressed when the patches are applied and the committer
is familiar with the code.
Scott :)
Jeanne Waldman wrote:
What is Matt saying that is different than what Andrew was saying?
We are going to require someone to check into both 1.2.X and 1.0.X,
correct?
This is a step in the right direction, and helps me out since I won't
have to do the merge if this goes through.
+1
- Jeanne
Scott O'Bryan wrote:
+1 to adding the trunk and I think Matt's suggestion is the best way
to do this without being too cumbersome.
Matt Cooper wrote:
+0 I have had troubles with the reverse structure of having the legacy
code on the trunk and the latest in a branch so I would like that to
switch too. As Jeanne points out, I think having 2 trunks would make
merging more difficult--at least if the rules remained as noted in
Adam's wiki. Now, if we were to apply patches as a one-by-one basis
and no no longer perform large trunk-to-branch style merging for
releases then this would be a big win. This would help to prevent
accidental merging of patches that are specific to a particular
release into the wrong release. This may not be what the vote is for
so my vote is just neutral for now.
Regards,
Matt
On Nov 15, 2007 12:09 PM, Martin Marinschek
<[EMAIL PROTECTED]> wrote:
+1,
regards,
Martin
On 11/15/07, Grant Smith <[EMAIL PROTECTED]> wrote:
+1, Andrew's suggestions make good sense.
On 11/15/07, Andrew Robinson <[EMAIL PROTECTED]> wrote:
On 11/15/07, Jeanne Waldman <[EMAIL PROTECTED]> wrote:
The same fix was in both, but one had different spacing.
Then it wasn't merged correctly and technically wasn't the same fix
from a repository point of view. With two active versions, ppl.
would
be responsible for using svn commands for putting a change set in
both
branches and not doing manual edits except for conflict resolution.
If ppl used the tool correctly, there should not be any such
conflicts.
Check Adam's wiki about merging the branches
Yes, this is assuming the current procedure without an active
branch on
JSF 1.2
- Jeanne
--
Grant Smith
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
