Dave wrote:
Drat. I hit the send button too soon. How about this: since we are basically done with Roller 4.0 features and we probably won't be adding any more, let's make the switch to the roller_4.0_newbackend branch now. svn mv trunk branches/roller_4.0_oldbackend svn mv branches/roller_4.0_newbackend trunk
after thinking about this a bit more i'm not sure this is the right way to promote code from a branch into the trunk. i realize this is the easy way to do it, but it seems to me that the trunk itself should remain intact and only the changes from the branch will be merged into the trunk.
i see two fairly significant problems with doing things the way you showed above ...
1. it's prone to errors which could cause us to lose part of the work from the trunk. basically, if at any point in time a change to the trunk was not properly merged into the branch then it gets lost and we would have no way of knowing it.
2. on a more serious note, when we do this we lose our versioning history and notes from all the work that happens on the trunk from the starting of the branch. updates to the branch only happen periodically and in large batches with the comments only saying "merging changes from [rev] to [rev]".
the subversion book offers a specific example of what we are trying to do, so i think we should follow that example ...
http://svnbook.red-bean.com/nightly/en/svn.branchmerge.commonuses.html -- Allen
We'll make JPA the default back-end but we'll keep Hibernate in place so that you can use it if you need to do any deployments or builds. I'll set up my build servers to test both the Hibernate and JPA implementations. And you can work exclusively in Hibernate if you wish and I'll take the JPA side, as we are doing now but in one branch instead of two. That will make it easy for folks (like Elias) to test JPA, easy for me to deploy JPA and will eliminate the dreadful merge work that is making the new installer and DI work a pain in the you know what. We could even make some early access builds available so others can help with testing -- we need a lot more testing this time because of Struts2 and JPA. The irritating double implementation business will only exist for a relatively short time: until we have enough confidence in JPA to delete Hibernate from SVN. Could that work? - Dave
