On 7/6/06, Jason Dillon <[EMAIL PROTECTED]> wrote:
On Jul 3, 2006, at 12:18 PM, Alan D. Cabrera wrote:
> The problem w/ migrating in a branch is that it gets out of date
> quickly. Since we're not using m2 in trunk anyway, why not just
> let Jason go crazy in trunk? If there are any changes that are
> needed in trunk that would affect the current build then for that
> bit, we go RTC; i.e. Jason should only be futzing w/ M2 POMs.
I agree with this... almost completely; I'd rather not say "go
crazy"... as it implies the wrong notion for what is going on. But
short of that I do believe that this is the right approach to getting
the build system upgraded.
I'm not a svn master and am not saying it will work, but...
Just done a quick test that verified I might be right that a branch
might eventually work. Here goes the story.
We create a branch - m2migration (it's done actually). Every change to
trunk is applied to the branch itself so we're sure it's kept updated.
After a day or two once we're satisfied with a very small change in
the branch, we let people vote - creating a diff (svn diff) and apply
it to a JIRA issue for review. That's where it needs to drift a little
from a common understanding - namely using unix patch. The UNIX patch
command doesn't work well with svn diff as described here -
http://svnbook.red-bean.com/nightly/en/svn.branchmerge.copychanges.html,
but svn merge does. When people are satisfied with reading, they can
apply the patch to their local repository using svn merge (nor patch
that doesn't work well). Once all are satisfied with the change, it
goes to trunk.
Comments?
--jason
Jacek
--
Jacek Laskowski
http://www.laskowski.net.pl
