I accidentally hijacked another thread. The user was talking about upgrading IDEs and it turns out his workspace was kept inside the nburn folder. I thought this an unwise approach, but several knowledgeable developers said this too is what they do. They liked the fact that they can just rename the nburn folder and they have a complete backup of their code and NDDK with which to build it. I see the benefit of that but it implied to me that they don't use a source code management system (SCM). That might not be true but it seems likely.
There appears to me to be quite a bit of pain involved in starting over with a new version of Eclipse and a new workspace every time a new NNDK is release. At a minimum, I have to re-import all the projects then synchronize all these folders with SVN. Then I have a lot of work to do to get Eclipse back to the state where it was, all the keyboard shortcuts, templates, formatting rules, plug-ins etc. There are export/import processes that would help with all this but the only benefit is that if I need to get back to an old version I can just rename the nburn folder and I'm good to go.
With my approach (assuming you're using an SCM with a branch/tag feature) I just tag my project when I change NNDKs. In the comment I put the version I moved from and the version I moved to. Then if I ever need the code base last used with a particular NNDK I can easily get it. I could also upload the NNDK to the SVN repository but they're so big I don't bother, I just rename it and keep it on my hard disk. My workspace and my copy of Eclipse live independently of the NNDK. I have updated through several iterations of the NNDK with zero pain this way. I do make a backup copy of my plug-ins folder in eclipse and then I move the plug-ins from the new NNDK into my Eclipse plug-in folder. Keeping your workspace and Eclipse inside the NNDK you are guaranteed pain, and probably resist moving to a new NNDK more than you should.
If you don't use an SCM see the #1 item on the list of 12 steps to better code. (The only caveat, please don't even consider using MS's Visual Source Safe as an SCM)
I started a new thread in case people want to chime in with their opinions and point out what a bone headed approach I'm taking.
Strategies for Moving to a new NNDK
Re: Strategies for Moving to a new NNDK
Hi Tod,
You are correct that I am not interfacing directly with version control. I do check things in/out of version control, but I do that outside of my workspace. I would agree with you that if you do interface directly with version control a workspace outside the install is a good idea. You can get back to any version of the code just as you stated, so it still works to get back to an old release. It seems like more work to me, but I'm probably not as good at interfacing to the version control system as you are. But if it was a large project with multiple developers working simultaneously, then that would be the preferred approach.
You are correct that I am not interfacing directly with version control. I do check things in/out of version control, but I do that outside of my workspace. I would agree with you that if you do interface directly with version control a workspace outside the install is a good idea. You can get back to any version of the code just as you stated, so it still works to get back to an old release. It seems like more work to me, but I'm probably not as good at interfacing to the version control system as you are. But if it was a large project with multiple developers working simultaneously, then that would be the preferred approach.
Re: Strategies for Moving to a new NNDK
You're right I'm tightly integrated with SVN and the bug tracking system. I do realize as a result of thinking about this, that at a minimum I should have been putting the NNDK version comment in EVERY tag release of my source code, not just when I switch NNDKs. It's probably not until you work with another programmer (where you both hit the remote SVN server) that you come to accept that the one true copy of the source code lives on the SVN server, not on your development machine. Trust in the cloud Luke.