There would be if there were changes in trunk that aren't also in branches/working-pluto. In this case there isn't anything in trunk that isn't in the branch that will become trunk so saving its state explicitly doesn't get us anything.

-Eric

William G. Thompson, Jr. wrote:
Eric,

Congrats and thanks for the all the work to date.  RU has a myRutgers
feature release going in this week, and then our attention will we be
focused on getting uP3 running locally and porting myRutgers to
it...our goal is to have uP3 in production for the Fall semester.

Sounds like you have a good plan.  I'm much more familiar with CVS
branch maintenance then SVN...is there any value in moving the trunk
to different branch rather then deleting it?

Bill

On Jan 8, 2008 9:57 AM, Eric Dalquist <[EMAIL PROTECTED]> wrote:
 The Pluto 1.l is pretty much complete. Render and Action work for portlets,
they play much better with CError (The IResetableChannel interface was added
to help with this), user attributes and portlet preferences are working,
caching is supported, dynamic titles should work.

 Syncing the portlet mode and window state with the theme layout preferences
is still on the todo list along with some minor work around the build
process. Once these are done I'll be tagging and releasing uPortal 3.0.0-M5.
I'll include with that release a list of all work done since 2.6 and ask for
peoples input on other changes or features they feel are required before a
release candidate is made.


 With this I plan on doing the following this morning to get the pluto code
merged back into the trunk:
 - svn delete the trunk
 - svn move the working-pluto branch to trunk

 Anyone that has the trunk checked out right now will need to re-check out.
I'd like to do the delete/move versus a merge because the extent of changes
in the working-pluto branch makes the prospect of merging quite daunting.

 -Eric




Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to