Thread: [Rainbowportal-devel] Re: [rainbowportal] Re: CVS Cleanup announce and a request for feedback
Brought to you by:
danijel_kecman,
manudea
From: Emmanuele De A. <ma...@gm...> - 2004-11-20 16:05:05
|
Inline On Sat, 20 Nov 2004 05:50:47 -0000, waveangle <ra...@cy...> wrote: > 1. Moving the ecommerce stuff somewhere out of the root of the web ui -- > very good. Keep the root of the project cleaner. :-) > 2. Why not merge Admin and AdminAll, they are close enough in purpose? Well this is scheduled later. In this first phase i do not want change page path. This may have implication. > 3. I'd like to see all the "model" code (as in model/view/controller) moved > to a separate project within the same solution, or if there are circular > dependencies, at least into one Model directory. Model code is configuration > classes, or anything related to the data and state of the portal. We started doing this on extension. We will do more in future. > 4. If you have a BLL, why not make it a separate class library? Well actually BLL covers only a small part of the project. > 5. I don't know why you have mixed purely administration modules in with the > user modules in DesktopModules. I don't need to customize admin tabs. I > don't even need the site admin to be part of the 'tab' structure. And you > don't have to have admin modules in the first place if you just use standard > forms. This flexible admin module system leads to a lot of initial confusion > over the setup and maintenance of Rainbow -- at least for me. I know my idea > will not be implemented but that's how I feel about it. This is a legacy inheritance of IBuyspy. Good but sometimes confusing. Gives you total freedom on doing your interface but at same time lacks of consistency. > 6. Can't you combine the DesktopPanes project into the Web UI project? It's > not that big and it would really help when starting to analyze the design of > the UI. It's difficult to find all the pieces. I will think about it... > 7. Not exactly cleanup, but I think with a little effort you can make > Rainbow a copyable project, as in Project/Copy Project? You are only missing > a few dlls in a file copy operation I think and you could use a few tricks > to force the copy to include them I think. Ok. Nice idea. When cleanup is nearly finished I will test it with copy project to fix all problems. > 8. Remove any dead unused experimental source files, or exclude them from > the project. Or put readme files in any optional or preliminary directories > to explain they are not needed. Can you list them? Which files you refer? > 9. Delete any unused empty directory. If an empty directory is required to > exist put a readme file to explain this. Can you list them? Which directories you refer? > 10. If any of the support files for a desktopmodule are under the UI > directory can't you move them all in with the module? UI folder keeps common code. Can you do a sample of thing that should be moved on module? Thanks for feedback Manu |
From: Mark A. G. <mgr...@gt...> - 2004-11-27 05:31:53
|
Can I ask why the tree is like this cvsroot/rainbowportal/CVSROOT/Rainbow/BLL why not like this cvsroot/rainbowportal/Rainbow/BLL thank you Mark -----Original Message----- From: Emmanuele De Andreis [mailto:ma...@gm...]=20 Sent: Thursday, 25 November 2004 7:37 AM To: rai...@li... Subject: [Rainbowportal-devel] Re: CVS Cleanup announce and a request for feedback Hi all The changes have propagated correctly. FOR CVS DEVELOPER WITH WRITE ACCESS: 1) BACKUP YOUR LOCAL COPY BEFORE GET NEW CVS. 2) BACKUP YOUR LOCAL COPY BEFORE GET NEW CVS. 3) BACKUP YOUR LOCAL COPY BEFORE GET NEW CVS. I strongly suggest to get CVS again in a fresh folder or remove the follow directories: cvsroot/rainbowportal/CVSROOT/Rainbow/BLL /cvsroot/rainbowportal/CVSROOT/Rainbow/Configuration /cvsroot/rainbowportal/CVSROOT/Rainbow/Helpers /cvsroot/rainbowportal/CVSROOT/Rainbow/KickStarter /cvsroot/rainbowportal/CVSROOT/Rainbow/Security /cvsroot/rainbowportal/CVSROOT/Rainbow/Service /cvsroot/rainbowportal/CVSROOT/Rainbow/UI /cvsroot/rainbowportal/CVSROOT/Rainbow/Ecommerce Changes commited in last 2 days may be removed... please upload again from your backup (because you have a backup,i told you 3 time to do it before get new cvs :-) ) Note: if you get: Value cannot be null. Parameter name: Resource not found: Rainbow.UI.WebControls.client_scripts.confirmDelete.js Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code. Exception Details: System.ArgumentNullException: Value cannot be null. Parameter name: Resource not found: Rainbow.UI.WebControls.client_scripts.confirmDelete.js You must upgrade your custom module to point to correct resource: Replace all "Rainbow.UI.WebControls.client_scripts.confirmDelete.js", "Rainbow.app_code.Rainbow.UI.WebControls.client_scripts.confirmDelete.js " the new repository module to get for have ecommerce is rainbowmodules (it is not fixed yet... I will do tomorrow. not sure but probably need more work... so please be patient) Please let me know any problem may raise from these changes... I will update project in few minutes. Anonymous client will get these in 24/48 hours from now. Manu On Tue, 23 Nov 2004 16:42:19 +0100, Emmanuele De Andreis <ma...@gm...> wrote: > This command was issued to sourceforge. > You can track here: > http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D1071803&grou= p_i d=3D1&atid=3D200001 >=20 > Be aware of all the issues i have pointed out before. > The project taken from CVS will not build until the project is changed > to reflect the move. Please BACKUP you local copy before update from > cvs. > This will be approx 48 hours after sourceforge will confirm the move > and all went fine on sf cvs side. > I will post here the result. Please stay tuned. >=20 >=20 >=20 > Manu >=20 > On Fri, 19 Nov 2004 11:23:16 +0100, Emmanuele De Andreis > <ma...@gm...> wrote: > > This is an announce and a request for feedback. > > I have scheduled these changes to be issued to source forge team on Monday. > > > > CVS Cleanup: rainbowportal > > > > I want to clean up the rainbow project tree. > > This is the first phase of a multiple phase clean up > > > > **************************************** > > PHASE 1 > > **************************************** > > In this phase I will move all code to a single tree. > > The path will resemble the namespace. > > > > Why: > > Easy of deployment (code directory can safely remain on your development pc) > > Easy of management (it is easy to find a cs file) > > > > Directory affected (and all subfolders of them): > > /cvsroot/rainbowportal/CVSROOT/Rainbow/BLL > > /cvsroot/rainbowportal/CVSROOT/Rainbow/Configuration > > /cvsroot/rainbowportal/CVSROOT/Rainbow/Helpers > > /cvsroot/rainbowportal/CVSROOT/Rainbow/KickStarter > > /cvsroot/rainbowportal/CVSROOT/Rainbow/Security > > /cvsroot/rainbowportal/CVSROOT/Rainbow/Service > > /cvsroot/rainbowportal/CVSROOT/Rainbow/UI > > > > Will be moved to: > > /cvsroot/rainbowportal/CVSROOT/app_code/Rainbow > > > > Why 'app_code'? > > app_code is the new convention chosen by aspnet 2.0 for store code > > related files. > > Rainbow is the default namespace every class have in rainbow.dll > > This will let us in future have other namespaces without mixing files. > > > > Users affected: > > CVS users and developers. > > > > Excpected issues: > > Minimal: we move only files. Namespaces and classes remain unchanged. > > If you use CVS you may loose you changes at first commit after the > > move, please backup any changes not committed before update. > > Rainbow cvs may not compile until solution is not upgraded to reflect > > new code position. This may happen a couple of day after moving. > > Embedded resource can be affected since moving means changing namespace. > > > > **************************************** > > PHASE 2 > > **************************************** > > In this phase I will move ecommerce related things to a separate module. > > Module will be called 'ecommerce' or 'modules/ecommerce' or > > 'extensions/ecommerce' > > > > Why: > > Rainbow core will be lighter. > > Ecommerce can be easily get from cvs any time. > > Rainbow core distributing (zipped or msi), will not include ecommerce > > anymore, but it will be available as separate download. > > > > Directory affected (and all subfolders of them): > > /cvsroot/rainbowportal/CVSROOT/Rainbow/ECommerce > > /cvsroot/rainbowportal/CVSROOT/BankGateway > > > > Files affected: > > /cvsroot/rainbowportal/CVSROOT/Rainbow/Ecommerce Nant Readme.txt > > /cvsroot/rainbowportal/CVSROOT/Rainbow/Ecommerce.build > > /cvsroot/rainbowportal/CVSROOT/Rainbow/ECommerce.csproj > > /cvsroot/rainbowportal/CVSROOT/Rainbow/ECommerce.csproj.webinfo > > /cvsroot/rainbowportal/CVSROOT/Rainbow/ECommerce.sln > > /cvsroot/rainbowportal/CVSROOT/Rainbow/ECommerce.suo > > /cvsroot/rainbowportal/CVSROOT/Rainbow/Ecommvs2nant.bat > > /cvsroot/rainbowportal/CVSROOT/Rainbow/UseEcommerceSolution.txt > > > > Will be moved to: > > /cvsroot/rainbowportal/ecommerce > > > > Alternatives: > > /cvsroot/rainbowportal/modules/ecommerce > > /cvsroot/rainbowportal/extensions/ecommerce > > > > Users affected: > > CVS users and Ecommerce users. > > > > Expected issues: > > Ecommerce users will have to install upgrades to ecommerce manually. > > If you use CVS you may loose you changes at first commit after the > > move, please backup any changes not committed before update. > > > ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now.=20 http://productguide.itmanagersjournal.com/ _______________________________________________ Rainbowportal-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel |
From: William L. F. <Bi...@im...> - 2004-11-27 06:39:57
Attachments:
smime.p7s
|
I said that a week ago when revision comments were first made. Manu = said that will happen, but it will be the last change after all the other = stuff is rearranged. At least, that's how I understood it. -----Original Message----- From: rai...@li... [mailto:rai...@li...] On Behalf Of = Mark A. Gregory Sent: Friday, November 26, 2004 9:46 PM To: rai...@li... Subject: RE: [Rainbowportal-devel] Re: CVS Cleanup announce and a = request for feedback Can I ask why the tree is like this cvsroot/rainbowportal/CVSROOT/Rainbow/BLL why not like this cvsroot/rainbowportal/Rainbow/BLL thank you Mark -----Original Message----- From: Emmanuele De Andreis [mailto:ma...@gm...]=20 Sent: Thursday, 25 November 2004 7:37 AM To: rai...@li... Subject: [Rainbowportal-devel] Re: CVS Cleanup announce and a request for feedback Hi all The changes have propagated correctly. FOR CVS DEVELOPER WITH WRITE ACCESS: 1) BACKUP YOUR LOCAL COPY BEFORE GET NEW CVS. 2) BACKUP YOUR LOCAL COPY BEFORE GET NEW CVS. 3) BACKUP YOUR LOCAL COPY BEFORE GET NEW CVS. I strongly suggest to get CVS again in a fresh folder or remove the follow directories: cvsroot/rainbowportal/CVSROOT/Rainbow/BLL /cvsroot/rainbowportal/CVSROOT/Rainbow/Configuration /cvsroot/rainbowportal/CVSROOT/Rainbow/Helpers /cvsroot/rainbowportal/CVSROOT/Rainbow/KickStarter /cvsroot/rainbowportal/CVSROOT/Rainbow/Security /cvsroot/rainbowportal/CVSROOT/Rainbow/Service /cvsroot/rainbowportal/CVSROOT/Rainbow/UI /cvsroot/rainbowportal/CVSROOT/Rainbow/Ecommerce Changes commited in last 2 days may be removed... please upload again from your backup (because you have a backup,i told you 3 time to do it before get new cvs :-) ) Note: if you get: Value cannot be null. Parameter name: Resource not found: Rainbow.UI.WebControls.client_scripts.confirmDelete.js Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code. Exception Details: System.ArgumentNullException: Value cannot be null. Parameter name: Resource not found: Rainbow.UI.WebControls.client_scripts.confirmDelete.js You must upgrade your custom module to point to correct resource: Replace all "Rainbow.UI.WebControls.client_scripts.confirmDelete.js", "Rainbow.app_code.Rainbow.UI.WebControls.client_scripts.confirmDelete.js " the new repository module to get for have ecommerce is rainbowmodules (it is not fixed yet... I will do tomorrow. not sure but probably need more work... so please be patient) Please let me know any problem may raise from these changes... I will update project in few minutes. Anonymous client will get these in 24/48 hours from now. Manu On Tue, 23 Nov 2004 16:42:19 +0100, Emmanuele De Andreis <ma...@gm...> wrote: > This command was issued to sourceforge. > You can track here: > http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D1071803&grou= p_i d=3D1&atid=3D200001 >=20 > Be aware of all the issues i have pointed out before. > The project taken from CVS will not build until the project is changed > to reflect the move. Please BACKUP you local copy before update from > cvs. > This will be approx 48 hours after sourceforge will confirm the move > and all went fine on sf cvs side. > I will post here the result. Please stay tuned. >=20 >=20 >=20 > Manu >=20 > On Fri, 19 Nov 2004 11:23:16 +0100, Emmanuele De Andreis > <ma...@gm...> wrote: > > This is an announce and a request for feedback. > > I have scheduled these changes to be issued to source forge team on Monday. > > > > CVS Cleanup: rainbowportal > > > > I want to clean up the rainbow project tree. > > This is the first phase of a multiple phase clean up > > > > **************************************** > > PHASE 1 > > **************************************** > > In this phase I will move all code to a single tree. > > The path will resemble the namespace. > > > > Why: > > Easy of deployment (code directory can safely remain on your development pc) > > Easy of management (it is easy to find a cs file) > > > > Directory affected (and all subfolders of them): > > /cvsroot/rainbowportal/CVSROOT/Rainbow/BLL > > /cvsroot/rainbowportal/CVSROOT/Rainbow/Configuration > > /cvsroot/rainbowportal/CVSROOT/Rainbow/Helpers > > /cvsroot/rainbowportal/CVSROOT/Rainbow/KickStarter > > /cvsroot/rainbowportal/CVSROOT/Rainbow/Security > > /cvsroot/rainbowportal/CVSROOT/Rainbow/Service > > /cvsroot/rainbowportal/CVSROOT/Rainbow/UI > > > > Will be moved to: > > /cvsroot/rainbowportal/CVSROOT/app_code/Rainbow > > > > Why 'app_code'? > > app_code is the new convention chosen by aspnet 2.0 for store code > > related files. > > Rainbow is the default namespace every class have in rainbow.dll > > This will let us in future have other namespaces without mixing files. > > > > Users affected: > > CVS users and developers. > > > > Excpected issues: > > Minimal: we move only files. Namespaces and classes remain unchanged. > > If you use CVS you may loose you changes at first commit after the > > move, please backup any changes not committed before update. > > Rainbow cvs may not compile until solution is not upgraded to reflect > > new code position. This may happen a couple of day after moving. > > Embedded resource can be affected since moving means changing namespace. > > > > **************************************** > > PHASE 2 > > **************************************** > > In this phase I will move ecommerce related things to a separate module. > > Module will be called 'ecommerce' or 'modules/ecommerce' or > > 'extensions/ecommerce' > > > > Why: > > Rainbow core will be lighter. > > Ecommerce can be easily get from cvs any time. > > Rainbow core distributing (zipped or msi), will not include ecommerce > > anymore, but it will be available as separate download. > > > > Directory affected (and all subfolders of them): > > /cvsroot/rainbowportal/CVSROOT/Rainbow/ECommerce > > /cvsroot/rainbowportal/CVSROOT/BankGateway > > > > Files affected: > > /cvsroot/rainbowportal/CVSROOT/Rainbow/Ecommerce Nant Readme.txt > > /cvsroot/rainbowportal/CVSROOT/Rainbow/Ecommerce.build > > /cvsroot/rainbowportal/CVSROOT/Rainbow/ECommerce.csproj > > /cvsroot/rainbowportal/CVSROOT/Rainbow/ECommerce.csproj.webinfo > > /cvsroot/rainbowportal/CVSROOT/Rainbow/ECommerce.sln > > /cvsroot/rainbowportal/CVSROOT/Rainbow/ECommerce.suo > > /cvsroot/rainbowportal/CVSROOT/Rainbow/Ecommvs2nant.bat > > /cvsroot/rainbowportal/CVSROOT/Rainbow/UseEcommerceSolution.txt > > > > Will be moved to: > > /cvsroot/rainbowportal/ecommerce > > > > Alternatives: > > /cvsroot/rainbowportal/modules/ecommerce > > /cvsroot/rainbowportal/extensions/ecommerce > > > > Users affected: > > CVS users and Ecommerce users. > > > > Expected issues: > > Ecommerce users will have to install upgrades to ecommerce manually. > > If you use CVS you may loose you changes at first commit after the > > move, please backup any changes not committed before update. > > > ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now.=20 http://productguide.itmanagersjournal.com/ _______________________________________________ Rainbowportal-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now.=20 http://productguide.itmanagersjournal.com/ _______________________________________________ Rainbowportal-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel =00 |
From: Emmanuele De A. <ma...@gm...> - 2004-11-27 21:32:38
|
We are moving arond a lot of things. I hope the reasult is a more clean an manageable cvs. Next steps may be: 1) Move most of the modules on rainbowmodules repository... (just like we did with ecommerce). Any module will have a project and will live in his folder. 2) Move rainbow main from CVSROOT to a rainbowcore or somethings (name can be decided on this list) 3) Create 2 different repository, one for STABLE brach and one for testing BRANCH or just branch it in same place. Both solution have pro and cons. I need some feedback on this Manu On Fri, 26 Nov 2004 22:34:49 -0800, William L. Forney <bi...@im...> wrote: > I said that a week ago when revision comments were first made. Manu said > that will happen, but it will be the last change after all the other stuff > is rearranged. At least, that's how I understood it. > > > > -----Original Message----- > From: rai...@li... > [mailto:rai...@li...] On Behalf Of Mark > A. Gregory > Sent: Friday, November 26, 2004 9:46 PM > To: rai...@li... > Subject: RE: [Rainbowportal-devel] Re: CVS Cleanup announce and a request > for feedback > > Can I ask why the tree is like this > cvsroot/rainbowportal/CVSROOT/Rainbow/BLL > > why not like this > > cvsroot/rainbowportal/Rainbow/BLL > > thank you > Mark > > -----Original Message----- > From: Emmanuele De Andreis [mailto:ma...@gm...] > Sent: Thursday, 25 November 2004 7:37 AM > To: rai...@li... > Subject: [Rainbowportal-devel] Re: CVS Cleanup announce and a request > for feedback > > Hi all > The changes have propagated correctly. > > FOR CVS DEVELOPER WITH WRITE ACCESS: > > 1) BACKUP YOUR LOCAL COPY BEFORE GET NEW CVS. > 2) BACKUP YOUR LOCAL COPY BEFORE GET NEW CVS. > 3) BACKUP YOUR LOCAL COPY BEFORE GET NEW CVS. > > I strongly suggest to get CVS again in a fresh folder or remove the > follow directories: > > cvsroot/rainbowportal/CVSROOT/Rainbow/BLL > /cvsroot/rainbowportal/CVSROOT/Rainbow/Configuration > /cvsroot/rainbowportal/CVSROOT/Rainbow/Helpers > /cvsroot/rainbowportal/CVSROOT/Rainbow/KickStarter > /cvsroot/rainbowportal/CVSROOT/Rainbow/Security > /cvsroot/rainbowportal/CVSROOT/Rainbow/Service > /cvsroot/rainbowportal/CVSROOT/Rainbow/UI > /cvsroot/rainbowportal/CVSROOT/Rainbow/Ecommerce > > Changes commited in last 2 days may be removed... please upload again > from your backup > (because you have a backup,i told you 3 time to do it before get new cvs > :-) ) > > Note: if you get: > Value cannot be null. Parameter name: Resource not found: > Rainbow.UI.WebControls.client_scripts.confirmDelete.js > Description: An unhandled exception occurred during the execution of > the current web request. Please review the stack trace for more > information about the error and where it originated in the code. > > Exception Details: System.ArgumentNullException: Value cannot be null. > Parameter name: Resource not found: > Rainbow.UI.WebControls.client_scripts.confirmDelete.js > > You must upgrade your custom module to point to correct resource: > Replace all "Rainbow.UI.WebControls.client_scripts.confirmDelete.js", > "Rainbow.app_code.Rainbow.UI.WebControls.client_scripts.confirmDelete.js > " > > the new repository module to get for have ecommerce is rainbowmodules > (it is not fixed yet... I will do tomorrow. not sure but probably need > more work... so please be patient) > > Please let me know any problem may raise from these changes... > > I will update project in few minutes. > Anonymous client will get these in 24/48 hours from now. > > Manu > > On Tue, 23 Nov 2004 16:42:19 +0100, Emmanuele De Andreis > <ma...@gm...> wrote: > > This command was issued to sourceforge. > > You can track here: > > > http://sourceforge.net/tracker/index.php?func=detail&aid=1071803&group_i > d=1&atid=200001 > > > > Be aware of all the issues i have pointed out before. > > The project taken from CVS will not build until the project is changed > > to reflect the move. Please BACKUP you local copy before update from > > cvs. > > This will be approx 48 hours after sourceforge will confirm the move > > and all went fine on sf cvs side. > > I will post here the result. Please stay tuned. > > > > > > > > Manu > > > > On Fri, 19 Nov 2004 11:23:16 +0100, Emmanuele De Andreis > > <ma...@gm...> wrote: > > > This is an announce and a request for feedback. > > > I have scheduled these changes to be issued to source forge team on > Monday. > > > > > > CVS Cleanup: rainbowportal > > > > > > I want to clean up the rainbow project tree. > > > This is the first phase of a multiple phase clean up > > > > > > **************************************** > > > PHASE 1 > > > **************************************** > > > In this phase I will move all code to a single tree. > > > The path will resemble the namespace. > > > > > > Why: > > > Easy of deployment (code directory can safely remain on your > development pc) > > > Easy of management (it is easy to find a cs file) > > > > > > Directory affected (and all subfolders of them): > > > /cvsroot/rainbowportal/CVSROOT/Rainbow/BLL > > > /cvsroot/rainbowportal/CVSROOT/Rainbow/Configuration > > > /cvsroot/rainbowportal/CVSROOT/Rainbow/Helpers > > > /cvsroot/rainbowportal/CVSROOT/Rainbow/KickStarter > > > /cvsroot/rainbowportal/CVSROOT/Rainbow/Security > > > /cvsroot/rainbowportal/CVSROOT/Rainbow/Service > > > /cvsroot/rainbowportal/CVSROOT/Rainbow/UI > > > > > > Will be moved to: > > > /cvsroot/rainbowportal/CVSROOT/app_code/Rainbow > > > > > > Why 'app_code'? > > > app_code is the new convention chosen by aspnet 2.0 for store code > > > related files. > > > Rainbow is the default namespace every class have in rainbow.dll > > > This will let us in future have other namespaces without mixing > files. > > > > > > Users affected: > > > CVS users and developers. > > > > > > Excpected issues: > > > Minimal: we move only files. Namespaces and classes remain > unchanged. > > > If you use CVS you may loose you changes at first commit after the > > > move, please backup any changes not committed before update. > > > Rainbow cvs may not compile until solution is not upgraded to > reflect > > > new code position. This may happen a couple of day after moving. > > > Embedded resource can be affected since moving means changing > namespace. > > > > > > **************************************** > > > PHASE 2 > > > **************************************** > > > In this phase I will move ecommerce related things to a separate > module. > > > Module will be called 'ecommerce' or 'modules/ecommerce' or > > > 'extensions/ecommerce' > > > > > > Why: > > > Rainbow core will be lighter. > > > Ecommerce can be easily get from cvs any time. > > > Rainbow core distributing (zipped or msi), will not include > ecommerce > > > anymore, but it will be available as separate download. > > > > > > Directory affected (and all subfolders of them): > > > /cvsroot/rainbowportal/CVSROOT/Rainbow/ECommerce > > > /cvsroot/rainbowportal/CVSROOT/BankGateway > > > > > > Files affected: > > > /cvsroot/rainbowportal/CVSROOT/Rainbow/Ecommerce Nant Readme.txt > > > /cvsroot/rainbowportal/CVSROOT/Rainbow/Ecommerce.build > > > /cvsroot/rainbowportal/CVSROOT/Rainbow/ECommerce.csproj > > > /cvsroot/rainbowportal/CVSROOT/Rainbow/ECommerce.csproj.webinfo > > > /cvsroot/rainbowportal/CVSROOT/Rainbow/ECommerce.sln > > > /cvsroot/rainbowportal/CVSROOT/Rainbow/ECommerce.suo > > > /cvsroot/rainbowportal/CVSROOT/Rainbow/Ecommvs2nant.bat > > > /cvsroot/rainbowportal/CVSROOT/Rainbow/UseEcommerceSolution.txt > > > > > > Will be moved to: > > > /cvsroot/rainbowportal/ecommerce > > > > > > Alternatives: > > > /cvsroot/rainbowportal/modules/ecommerce > > > /cvsroot/rainbowportal/extensions/ecommerce > > > > > > Users affected: > > > CVS users and Ecommerce users. > > > > > > Expected issues: > > > Ecommerce users will have to install upgrades to ecommerce manually. > > > If you use CVS you may loose you changes at first commit after the > > > move, please backup any changes not committed before update. > > > > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://productguide.itmanagersjournal.com/ > _______________________________________________ > Rainbowportal-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://productguide.itmanagersjournal.com/ > _______________________________________________ > Rainbowportal-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel > > > |
From: Joerg S. <j.s...@fe...> - 2004-11-28 10:04:23
|
> 1) Move most of the modules on rainbowmodules repository... (just like > we did with ecommerce). Any module will have a project and will live > in his folder. Sounds good to me. Also every module should have ist on DLL. > 2) Move rainbow main from CVSROOT to a rainbowcore or somethings (name > can be decided on this list) That would be great and will help to build custom modules without the need to change the core code. That is my problem right now. I changed on a project the core code. So it is not realy easy to update Rainbow. > 3) Create 2 different repository, one for STABLE brach and one for > testing BRANCH or just branch it in same place. Both solution have pro > and cons. How that would work? kind regards Joerg |
From: Emmanuele De A. <ma...@gm...> - 2004-11-28 22:17:28
|
We need a stable rainbow with no bugs and at same time we need to puch forward improvement and new features. How can we manage this? 2 repositries? or 2 branches? 2 repositories live different lives, are totally independent so are 2 products indeed... only developers can move things between 2 releases; this give maximum freedom: eg we can move dir layout without affect the other. Once something is named 1.5 for example -- bug fixes can be made to 1.5 but no new additions. Branch is a cvs feature that allows many versions share same repository so you can checkout the version 1.5 or 1.6 cvs knows which file get and commit. Branch is the cvs feature that allows having 2 version, stables and unstable we want no way for the person to accidentally get unstable version. The only problem I see is that most of developers have no big experience in cvs and can make mistakes. 2 repositories means more difficulties to reconcile version... Look at this scenario: 1.5 is stable, 1.6 is unstable; at some point 1.6 has 3/4 feature very stable and we want to release in stable, we have to move these feature by hand... no help from cvs For some in depth reading: http://www.psc.edu/~semke/cvs_branches.html How a complex software like KDE manages cvs branches: http://kdevelop.org/index.html?filename=HEAD/branches_compiling.html&set_lang=en NB: the HEAD branch is the default branch and the one you get now if you want to get rainbow. This means getting the latest version. Having more than one branch means you can just checkout 2 branches in 2 different directories on your disk and work as they are separate projects. It is easy enough get the correct branch with tortoise. As a side note I suggest this good reading: Working on Free Software http://www106.pair.com/rhp/hacking.html On Sun, 28 Nov 2004 11:03:28 +0100, Joerg Szepan <j.s...@fe...> wrote: > > 1) Move most of the modules on rainbowmodules repository... (just > like > > we did with ecommerce). Any module will have a project and will live > > in his folder. > > Sounds good to me. Also every module should have ist on DLL. > > > 2) Move rainbow main from CVSROOT to a rainbowcore or somethings > (name > > can be decided on this list) > > That would be great and will help to build custom modules without the > need > to change the core code. That is my problem right now. I changed on a > project > the core code. So it is not realy easy to update Rainbow. > > > 3) Create 2 different repository, one for STABLE brach and one for > > testing BRANCH or just branch it in same place. Both solution have > pro > > and cons. > > How that would work? > > kind regards > Joerg > > ------------------------------------------------------- > > > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://productguide.itmanagersjournal.com/ > _______________________________________________ > Rainbowportal-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel > |
From: Charles M. C. <91...@le...> - 2004-11-29 01:31:34
|
At 05:17 PM 11/28/2004, you wrote: >We need a stable rainbow with no bugs and at same time we need to puch >forward improvement and new features. How can we manage this? 2 >repositries? or 2 branches? >2 repositories live different lives, are totally independent so are 2 >products indeed... only developers can move things between 2 releases; >this give maximum freedom: eg we can move dir layout without affect >the other. Once something is named 1.5 for example -- bug fixes can be >made to 1.5 but no new additions. Branch is a cvs feature that allows >many versions share same repository so you can checkout the version >1.5 or 1.6 cvs knows which file get and commit. Branch is the cvs >feature that allows having 2 version, stables and unstable we want no >way for the person to accidentally get unstable version. The only >problem I see is that most of developers have no big experience in cvs >and can make mistakes. >2 repositories means more difficulties to reconcile version... Look at >this scenario: 1.5 is stable, 1.6 is unstable; at some point 1.6 has >3/4 feature very stable and we want to release in stable, we have to >move these feature by hand... no help from cvs I think you misunderstand that it is wise to move new changes back to old versions. My suggestion is that a branch is not the way to go; it is the path to Forks -- which can be very hard to reconcile. My opinion is based on the following high level view of what we are trying to achieve. Microsoft does not backport all features to very old version of Windows, but people run those old versions. As an example: A RepositoryV# (RepositoryV1.5 for example) will always be 1.5 although it may be incremented by minor version #'s as we fix past bugs. 1.500 1.501 1.502 1.503 etc. That repository will always be available any time in the future. It will include a site upgrade/migrate tool from last version to this one. The RepositoryVnext is based on starts with the last stable version and all the mods onward are destined to become the next version. When the testers declare it stable, it becomes a RepositoryV# (RepostioryV2.0 for example) and then placed into a dedicated repository. Now this repository is declared stable and will always be available any time in the future. It will get minor bug fixes and minor number increments - those can be built as tags. Now the cycle begins again. And the landscape for new visitors looks like RepositoryV1.5 - available for download - contains n modules - contains n themes - can migrate from Vlast - will have one or more tags leading to bug fixed versions RepositoryV2.0 - available for download - contains n modules - contains n themes - can migrate from Vlast after chaining all past migration tools - will have one or more tags leading to bug fixed versions RepositoryBeta - starts with last release + team adds new code and makes changes - available for downloads/experiments/preview - contains n modules - contains n themes - may not be stable or perfect - may have one or more tags - can migrate from Vlast after chaining all past migration tools When one wants to work with a client with a Rainbow install they can keep the client on the exact build that client worked with except they may want to install the latest tag for bug fixes. Modules and Migration tools can then be able to know what versions are out there, indicate which versions they have been tested and are compatible with, and react upon setup appropriately. The RepositoryVnext build can have migration tools for any versions it can pull in data for. At least a migration tools is working against 1 last version as opposed to dozens and hundreds of dated builds. If migration tools are designed right as long as each version has a migration tool from Vlast, the Preview version should be able to successively run the migration tools in sequence, and get old versions up to VLast. Then assume it's migration tool merely deals with Vlast to Vcurrent and invokes the older migration tools in order as appropriate. There may be better ways to accomplish this high level scenario which Is why I laid out the goals as I see them -- in case there is an even better way to get there that does not use Tags. >For some in depth reading: >http://www.psc.edu/~semke/cvs_branches.html > >How a complex software like KDE manages cvs branches: >http://kdevelop.org/index.html?filename=HEAD/branches_compiling.html&set_lang=en > >NB: the HEAD branch is the default branch and the one you get now if >you want to get rainbow. This means getting the latest version. >Having more than one branch means you can just checkout 2 branches in >2 different directories on your disk and work as they are separate >projects. >It is easy enough get the correct branch with tortoise. > >As a side note I suggest this good reading: >Working on Free Software >http://www106.pair.com/rhp/hacking.html |
From: William F. <WF...@im...> - 2004-11-29 02:48:36
|
Has anyone checked out www.tigris.org and svn? SVN manages folders as well as just files and supports a lot of things cvs has problems with. Just curious if anyone is using it instead of cvs in production. -----Original Message----- From: rai...@li... [mailto:rai...@li...] On Behalf Of Emmanuele De Andreis Sent: Sunday, November 28, 2004 2:46 PM To: rai...@li... Subject: Re: [Rainbowportal-devel] Re: CVS Cleanup announce and a request for feedback We need a stable rainbow with no bugs and at same time we need to puch forward improvement and new features. How can we manage this? 2 repositries? or 2 branches? 2 repositories live different lives, are totally independent so are 2 products indeed... only developers can move things between 2 releases; this give maximum freedom: eg we can move dir layout without affect the other. Once something is named 1.5 for example -- bug fixes can be made to 1.5 but no new additions. Branch is a cvs feature that allows many versions share same repository so you can checkout the version 1.5 or 1.6 cvs knows which file get and commit. Branch is the cvs feature that allows having 2 version, stables and unstable we want no way for the person to accidentally get unstable version. The only problem I see is that most of developers have no big experience in cvs and can make mistakes. 2 repositories means more difficulties to reconcile version... Look at this scenario: 1.5 is stable, 1.6 is unstable; at some point 1.6 has 3/4 feature very stable and we want to release in stable, we have to move these feature by hand... no help from cvs For some in depth reading: http://www.psc.edu/~semke/cvs_branches.html How a complex software like KDE manages cvs branches: http://kdevelop.org/index.html?filename=3DHEAD/branches_compiling.html&se= t _lang=3Den NB: the HEAD branch is the default branch and the one you get now if you want to get rainbow. This means getting the latest version. Having more than one branch means you can just checkout 2 branches in 2 different directories on your disk and work as they are separate projects. It is easy enough get the correct branch with tortoise. As a side note I suggest this good reading: Working on Free Software http://www106.pair.com/rhp/hacking.html On Sun, 28 Nov 2004 11:03:28 +0100, Joerg Szepan <j.s...@fe...> wrote: > > 1) Move most of the modules on rainbowmodules repository... (just > like > > we did with ecommerce). Any module will have a project and will live > > in his folder. >=20 > Sounds good to me. Also every module should have ist on DLL. >=20 > > 2) Move rainbow main from CVSROOT to a rainbowcore or somethings > (name > > can be decided on this list) >=20 > That would be great and will help to build custom modules without the > need > to change the core code. That is my problem right now. I changed on a > project > the core code. So it is not realy easy to update Rainbow. >=20 > > 3) Create 2 different repository, one for STABLE brach and one for > > testing BRANCH or just branch it in same place. Both solution have > pro > > and cons. >=20 > How that would work? >=20 > kind regards > Joerg >=20 > ------------------------------------------------------- >=20 >=20 > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://productguide.itmanagersjournal.com/ > _______________________________________________ > Rainbowportal-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel > ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now.=20 http://productguide.itmanagersjournal.com/ _______________________________________________ Rainbowportal-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel |
From: Rahul S. <ana...@gm...> - 2004-11-29 20:24:27
|
I have used SVN in production and it rocks. I have suggested it to Manu, and possibly to this list before. Rahul On Sun, 28 Nov 2004 18:48:13 -0800, William Forney <wf...@im...> wrote: > Has anyone checked out www.tigris.org and svn? SVN manages folders as > well as just files and supports a lot of things cvs has problems with. > Just curious if anyone is using it instead of cvs in production. > > > > -----Original Message----- > From: rai...@li... > [mailto:rai...@li...] On Behalf Of > Emmanuele De Andreis > Sent: Sunday, November 28, 2004 2:46 PM > To: rai...@li... > Subject: Re: [Rainbowportal-devel] Re: CVS Cleanup announce and a > request for feedback > > We need a stable rainbow with no bugs and at same time we need to puch > forward improvement and new features. How can we manage this? 2 > repositries? or 2 branches? > 2 repositories live different lives, are totally independent so are 2 > products indeed... only developers can move things between 2 releases; > this give maximum freedom: eg we can move dir layout without affect > the other. Once something is named 1.5 for example -- bug fixes can be > made to 1.5 but no new additions. Branch is a cvs feature that allows > many versions share same repository so you can checkout the version > 1.5 or 1.6 cvs knows which file get and commit. Branch is the cvs > feature that allows having 2 version, stables and unstable we want no > way for the person to accidentally get unstable version. The only > problem I see is that most of developers have no big experience in cvs > and can make mistakes. > 2 repositories means more difficulties to reconcile version... Look at > this scenario: 1.5 is stable, 1.6 is unstable; at some point 1.6 has > 3/4 feature very stable and we want to release in stable, we have to > move these feature by hand... no help from cvs > > For some in depth reading: > http://www.psc.edu/~semke/cvs_branches.html > > How a complex software like KDE manages cvs branches: > http://kdevelop.org/index.html?filename=HEAD/branches_compiling.html&set > _lang=en > > NB: the HEAD branch is the default branch and the one you get now if > you want to get rainbow. This means getting the latest version. > Having more than one branch means you can just checkout 2 branches in > 2 different directories on your disk and work as they are separate > projects. > It is easy enough get the correct branch with tortoise. > > As a side note I suggest this good reading: > Working on Free Software > http://www106.pair.com/rhp/hacking.html > > On Sun, 28 Nov 2004 11:03:28 +0100, Joerg Szepan > <j.s...@fe...> wrote: > > > 1) Move most of the modules on rainbowmodules repository... (just > > like > > > we did with ecommerce). Any module will have a project and will live > > > in his folder. > > > > Sounds good to me. Also every module should have ist on DLL. > > > > > 2) Move rainbow main from CVSROOT to a rainbowcore or somethings > > (name > > > can be decided on this list) > > > > That would be great and will help to build custom modules without the > > need > > to change the core code. That is my problem right now. I changed on a > > project > > the core code. So it is not realy easy to update Rainbow. > > > > > 3) Create 2 different repository, one for STABLE brach and one for > > > testing BRANCH or just branch it in same place. Both solution have > > pro > > > and cons. > > > > How that would work? > > > > kind regards > > Joerg > > > > ------------------------------------------------------- > > > > > > SF email is sponsored by - The IT Product Guide > > Read honest & candid reviews on hundreds of IT Products from real > users. > > Discover which products truly live up to the hype. Start reading now. > > http://productguide.itmanagersjournal.com/ > > _______________________________________________ > > Rainbowportal-devel mailing list > > Rai...@li... > > https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://productguide.itmanagersjournal.com/ > _______________________________________________ > Rainbowportal-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://productguide.itmanagersjournal.com/ > _______________________________________________ > Rainbowportal-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel > |
From: Emmanuele De A. <ma...@gm...> - 2004-11-29 20:38:18
|
I have not tested it but I have nothing against it. Sourceforge does not support it. http://sourceforge.net/docman/display_doc.php?docid=14033&group_id=1#alternateversioning So if we really want to migrate we need a sponsor that offer that service. I already manage too many rb related sites and have not time to invest in setup and mantain something like that. Which would be the best advantages for us on migrating? Manu On Mon, 29 Nov 2004 15:24:14 -0500, Rahul Singh <ana...@gm...> wrote: > I have used SVN in production and it rocks. I have suggested it to > Manu, and possibly to this list before. > > Rahul > > On Sun, 28 Nov 2004 18:48:13 -0800, William Forney > > > <wf...@im...> wrote: > > Has anyone checked out www.tigris.org and svn? SVN manages folders as > > well as just files and supports a lot of things cvs has problems with. > > Just curious if anyone is using it instead of cvs in production. > > > > > > > > -----Original Message----- > > From: rai...@li... > > [mailto:rai...@li...] On Behalf Of > > Emmanuele De Andreis > > Sent: Sunday, November 28, 2004 2:46 PM > > To: rai...@li... > > Subject: Re: [Rainbowportal-devel] Re: CVS Cleanup announce and a > > request for feedback > > > > We need a stable rainbow with no bugs and at same time we need to puch > > forward improvement and new features. How can we manage this? 2 > > repositries? or 2 branches? > > 2 repositories live different lives, are totally independent so are 2 > > products indeed... only developers can move things between 2 releases; > > this give maximum freedom: eg we can move dir layout without affect > > the other. Once something is named 1.5 for example -- bug fixes can be > > made to 1.5 but no new additions. Branch is a cvs feature that allows > > many versions share same repository so you can checkout the version > > 1.5 or 1.6 cvs knows which file get and commit. Branch is the cvs > > feature that allows having 2 version, stables and unstable we want no > > way for the person to accidentally get unstable version. The only > > problem I see is that most of developers have no big experience in cvs > > and can make mistakes. > > 2 repositories means more difficulties to reconcile version... Look at > > this scenario: 1.5 is stable, 1.6 is unstable; at some point 1.6 has > > 3/4 feature very stable and we want to release in stable, we have to > > move these feature by hand... no help from cvs > > > > For some in depth reading: > > http://www.psc.edu/~semke/cvs_branches.html > > > > How a complex software like KDE manages cvs branches: > > http://kdevelop.org/index.html?filename=HEAD/branches_compiling.html&set > > _lang=en > > > > NB: the HEAD branch is the default branch and the one you get now if > > you want to get rainbow. This means getting the latest version. > > Having more than one branch means you can just checkout 2 branches in > > 2 different directories on your disk and work as they are separate > > projects. > > It is easy enough get the correct branch with tortoise. > > > > As a side note I suggest this good reading: > > Working on Free Software > > http://www106.pair.com/rhp/hacking.html > > > > On Sun, 28 Nov 2004 11:03:28 +0100, Joerg Szepan > > <j.s...@fe...> wrote: > > > > 1) Move most of the modules on rainbowmodules repository... (just > > > like > > > > we did with ecommerce). Any module will have a project and will live > > > > in his folder. > > > > > > Sounds good to me. Also every module should have ist on DLL. > > > > > > > 2) Move rainbow main from CVSROOT to a rainbowcore or somethings > > > (name > > > > can be decided on this list) > > > > > > That would be great and will help to build custom modules without the > > > need > > > to change the core code. That is my problem right now. I changed on a > > > project > > > the core code. So it is not realy easy to update Rainbow. > > > > > > > 3) Create 2 different repository, one for STABLE brach and one for > > > > testing BRANCH or just branch it in same place. Both solution have > > > pro > > > > and cons. > > > > > > How that would work? > > > > > > kind regards > > > Joerg > > > > > > ------------------------------------------------------- > > > > > > > > > SF email is sponsored by - The IT Product Guide > > > Read honest & candid reviews on hundreds of IT Products from real > > users. > > > Discover which products truly live up to the hype. Start reading now. > > > http://productguide.itmanagersjournal.com/ > > > _______________________________________________ > > > Rainbowportal-devel mailing list > > > Rai...@li... > > > https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel > > > > > > > ------------------------------------------------------- > > SF email is sponsored by - The IT Product Guide > > Read honest & candid reviews on hundreds of IT Products from real users. > > Discover which products truly live up to the hype. Start reading now. > > http://productguide.itmanagersjournal.com/ > > _______________________________________________ > > Rainbowportal-devel mailing list > > Rai...@li... > > https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel > > > > ------------------------------------------------------- > > SF email is sponsored by - The IT Product Guide > > Read honest & candid reviews on hundreds of IT Products from real users. > > Discover which products truly live up to the hype. Start reading now. > > http://productguide.itmanagersjournal.com/ > > _______________________________________________ > > Rainbowportal-devel mailing list > > Rai...@li... > > https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://productguide.itmanagersjournal.com/ > _______________________________________________ > Rainbowportal-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel > |
From: Mark A. G. <mgr...@gt...> - 2004-11-30 01:19:09
|
Thank you William, I'm a little behind everyone here :) Mark -----Original Message----- From: William L. Forney [mailto:Bi...@im...]=20 Sent: Saturday, 27 November 2004 5:35 PM To: rai...@li... Subject: RE: [Rainbowportal-devel] Re: CVS Cleanup announce and a request for feedback I said that a week ago when revision comments were first made. Manu said that will happen, but it will be the last change after all the other stuff is rearranged. At least, that's how I understood it. -----Original Message----- From: rai...@li... [mailto:rai...@li...] On Behalf Of Mark A. Gregory Sent: Friday, November 26, 2004 9:46 PM To: rai...@li... Subject: RE: [Rainbowportal-devel] Re: CVS Cleanup announce and a request for feedback Can I ask why the tree is like this cvsroot/rainbowportal/CVSROOT/Rainbow/BLL why not like this cvsroot/rainbowportal/Rainbow/BLL thank you Mark -----Original Message----- From: Emmanuele De Andreis [mailto:ma...@gm...]=20 Sent: Thursday, 25 November 2004 7:37 AM To: rai...@li... Subject: [Rainbowportal-devel] Re: CVS Cleanup announce and a request for feedback Hi all The changes have propagated correctly. FOR CVS DEVELOPER WITH WRITE ACCESS: 1) BACKUP YOUR LOCAL COPY BEFORE GET NEW CVS. 2) BACKUP YOUR LOCAL COPY BEFORE GET NEW CVS. 3) BACKUP YOUR LOCAL COPY BEFORE GET NEW CVS. I strongly suggest to get CVS again in a fresh folder or remove the follow directories: cvsroot/rainbowportal/CVSROOT/Rainbow/BLL /cvsroot/rainbowportal/CVSROOT/Rainbow/Configuration /cvsroot/rainbowportal/CVSROOT/Rainbow/Helpers /cvsroot/rainbowportal/CVSROOT/Rainbow/KickStarter /cvsroot/rainbowportal/CVSROOT/Rainbow/Security /cvsroot/rainbowportal/CVSROOT/Rainbow/Service /cvsroot/rainbowportal/CVSROOT/Rainbow/UI /cvsroot/rainbowportal/CVSROOT/Rainbow/Ecommerce Changes commited in last 2 days may be removed... please upload again from your backup (because you have a backup,i told you 3 time to do it before get new cvs :-) ) Note: if you get: Value cannot be null. Parameter name: Resource not found: Rainbow.UI.WebControls.client_scripts.confirmDelete.js Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code. Exception Details: System.ArgumentNullException: Value cannot be null. Parameter name: Resource not found: Rainbow.UI.WebControls.client_scripts.confirmDelete.js You must upgrade your custom module to point to correct resource: Replace all "Rainbow.UI.WebControls.client_scripts.confirmDelete.js", "Rainbow.app_code.Rainbow.UI.WebControls.client_scripts.confirmDelete.js " the new repository module to get for have ecommerce is rainbowmodules (it is not fixed yet... I will do tomorrow. not sure but probably need more work... so please be patient) Please let me know any problem may raise from these changes... I will update project in few minutes. Anonymous client will get these in 24/48 hours from now. Manu On Tue, 23 Nov 2004 16:42:19 +0100, Emmanuele De Andreis <ma...@gm...> wrote: > This command was issued to sourceforge. > You can track here: > http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D1071803&grou= p_i d=3D1&atid=3D200001 >=20 > Be aware of all the issues i have pointed out before. > The project taken from CVS will not build until the project is changed > to reflect the move. Please BACKUP you local copy before update from > cvs. > This will be approx 48 hours after sourceforge will confirm the move > and all went fine on sf cvs side. > I will post here the result. Please stay tuned. >=20 >=20 >=20 > Manu >=20 > On Fri, 19 Nov 2004 11:23:16 +0100, Emmanuele De Andreis > <ma...@gm...> wrote: > > This is an announce and a request for feedback. > > I have scheduled these changes to be issued to source forge team on Monday. > > > > CVS Cleanup: rainbowportal > > > > I want to clean up the rainbow project tree. > > This is the first phase of a multiple phase clean up > > > > **************************************** > > PHASE 1 > > **************************************** > > In this phase I will move all code to a single tree. > > The path will resemble the namespace. > > > > Why: > > Easy of deployment (code directory can safely remain on your development pc) > > Easy of management (it is easy to find a cs file) > > > > Directory affected (and all subfolders of them): > > /cvsroot/rainbowportal/CVSROOT/Rainbow/BLL > > /cvsroot/rainbowportal/CVSROOT/Rainbow/Configuration > > /cvsroot/rainbowportal/CVSROOT/Rainbow/Helpers > > /cvsroot/rainbowportal/CVSROOT/Rainbow/KickStarter > > /cvsroot/rainbowportal/CVSROOT/Rainbow/Security > > /cvsroot/rainbowportal/CVSROOT/Rainbow/Service > > /cvsroot/rainbowportal/CVSROOT/Rainbow/UI > > > > Will be moved to: > > /cvsroot/rainbowportal/CVSROOT/app_code/Rainbow > > > > Why 'app_code'? > > app_code is the new convention chosen by aspnet 2.0 for store code > > related files. > > Rainbow is the default namespace every class have in rainbow.dll > > This will let us in future have other namespaces without mixing files. > > > > Users affected: > > CVS users and developers. > > > > Excpected issues: > > Minimal: we move only files. Namespaces and classes remain unchanged. > > If you use CVS you may loose you changes at first commit after the > > move, please backup any changes not committed before update. > > Rainbow cvs may not compile until solution is not upgraded to reflect > > new code position. This may happen a couple of day after moving. > > Embedded resource can be affected since moving means changing namespace. > > > > **************************************** > > PHASE 2 > > **************************************** > > In this phase I will move ecommerce related things to a separate module. > > Module will be called 'ecommerce' or 'modules/ecommerce' or > > 'extensions/ecommerce' > > > > Why: > > Rainbow core will be lighter. > > Ecommerce can be easily get from cvs any time. > > Rainbow core distributing (zipped or msi), will not include ecommerce > > anymore, but it will be available as separate download. > > > > Directory affected (and all subfolders of them): > > /cvsroot/rainbowportal/CVSROOT/Rainbow/ECommerce > > /cvsroot/rainbowportal/CVSROOT/BankGateway > > > > Files affected: > > /cvsroot/rainbowportal/CVSROOT/Rainbow/Ecommerce Nant Readme.txt > > /cvsroot/rainbowportal/CVSROOT/Rainbow/Ecommerce.build > > /cvsroot/rainbowportal/CVSROOT/Rainbow/ECommerce.csproj > > /cvsroot/rainbowportal/CVSROOT/Rainbow/ECommerce.csproj.webinfo > > /cvsroot/rainbowportal/CVSROOT/Rainbow/ECommerce.sln > > /cvsroot/rainbowportal/CVSROOT/Rainbow/ECommerce.suo > > /cvsroot/rainbowportal/CVSROOT/Rainbow/Ecommvs2nant.bat > > /cvsroot/rainbowportal/CVSROOT/Rainbow/UseEcommerceSolution.txt > > > > Will be moved to: > > /cvsroot/rainbowportal/ecommerce > > > > Alternatives: > > /cvsroot/rainbowportal/modules/ecommerce > > /cvsroot/rainbowportal/extensions/ecommerce > > > > Users affected: > > CVS users and Ecommerce users. > > > > Expected issues: > > Ecommerce users will have to install upgrades to ecommerce manually. > > If you use CVS you may loose you changes at first commit after the > > move, please backup any changes not committed before update. > > > ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now.=20 http://productguide.itmanagersjournal.com/ _______________________________________________ Rainbowportal-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now.=20 http://productguide.itmanagersjournal.com/ _______________________________________________ Rainbowportal-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel |