> I would have highly preferred Tim put the new silver in /silver, > and keep branches/daly as his private branch; but he didn't so we must > learn to live with that.
I put the code into branches/daly because it's not ready yet. That code is the first version that passed all of the tests. However there are still many things to fix and I'm going thru the bug list now looking for fixes. That code will change in various ways (e.g. I'm downcasing filenames to conform to windows/mac and many files will change in an upcoming changeset). The code isn't "silver" yet so I put it on a private branch while I do the work in public. > As for merge, it is going to be more painful than it has to be > primaily because Tim picked changes by carefully not picking the > revision number or ChangeLogs. When you make changes do you try to merge them with Gold and then publish either a diff-Naur or a revision number? The revision number selection involves changesets which almost always include Makefile changes. But Gold does not have a matching Makefile so the changeset merge won't work. Perhaps the failure is due to my lack of understanding of how SVN merge is supposed to work. However I don't see how SVN merge can possibly be expected to merge a BI Makefile and a Gold Makefile. > I tried twice, but abandoned because I had more pressing things > on the fire and partly because I got frustrated. I understand your frustration. I started this whole merge process in the late january time frame and have been working on it exclusively since then. You've been doing valuable work and I tried to pick up what I could so it could be in the next release. It seems to me that the "responsibility" criteria is somehow reversed. If you or anyone else develops a change to the system doesn't it seem reasonable that you are responsible for documenting, diffing, creating changesets, creating test cases, and packaging up the changes so they fit into what the current Gold version is? I see good work being done but I see no effort on your part to lift it out of your private sandbox. Tim _______________________________________________ Axiom-developer mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/axiom-developer
