Managing projects in CCSv4 - Can't use "import existing CCS/CCE Eclipse Project" option

Thanks for the response

It sure would be nice to have an app that changes the meta data, or even better, to have the import window allow a user to change the project metadata to the folder name. Changing the meta data is already available when one wants to change the project name when using the CCSv4 project viewer. A button that says "show duplicate projects" and then the option to change the name would be really handy.

Then CCSv4 would be similar to the workspace paridigm that us ol'CCSv3.3 people are used to whereby we can have multiple projects open that are based on the same code base, but are used for different change requests.

This feature would only be useful for Subversion checkouts. For clearcase, I think one is stuck with doing multiple workspaces as you suggest.

But now that I've pondered on the ramifications to change the project name, it seems that this would not be a good idea. The person checking out the code base would then check the project back in with different project name that would cause confusion in a multi-developer environment.

Cheers

Now that I've tried using multiple workspaces, I not a lover of that option. For what its worth, can a feature be added to allow one to have multiple projects of the same name in one workspace (like what can be done in CCSv3?)

It would seem that many others would also want to have this feature.

Cheers

Eddie,

I registered your suggestion in the enhancement number SDSCM00035750. Please check its status at the external bug database (the SDOWP link in my signature below).

Usually engineering looks into these issues in a timely manner. Please check back regularly.

Best regards,

Rafael

Thanks!

I'm running into a similar issue in migrating our projects to CCSv4.  We have .pjt files with the same name (but going to different targets).  CCSv4 won't allow you to import v3.3 projects if they have the same name even though they are in unique folders.  So I have to first rename the projects and then migrate.  We'd like to keep the convention of having same project names but run on different targets.  However, CCSv4 currently will not let us do this unless we have different workspace (which creates other development issues).

Hopefully this enhancement gets implemented soon!

Mike

Mike,

The enhancement filed is to allow changing the name of the project before importing it to the workspace. From your post I get that you want to have the same project name but with different locations, is that so?

If so, unfortunately Eclipse does not allow same name projects to coexist in the workspace. Although in theory anything can be changed in software, in practice this violates Eclipse guidelines and can potentially break compatibility with other tools and plug-ins.

The Eclipse documentation states that Each node (other than the root) is one of the three kinds of resources, and each has a name that is different from its siblings. Check the link below, which talks about the workspace and resources (projects, files, folders):
http://help.eclipse.org/help33/index.jsp?topic=/org.eclipse.platform.doc.isv/guide/resInt_workspace.htm

Best regards,
Rafael

Rafael,

Thanks for the feedback.  It seems like in CCSv4, I have 2 options: change the name of duplicate projects to unique names or use multiple workspaces.  Which would you recommend?  Here is a summary or our folder structure in source control:

<root>---<algorithms>

           ---<projects>---<hw_target1>---<board_test>

                                                               ---<customer_app1>

                                  ---<hw_target2>---<board_test>

                                                              ---<customer_app1>

           ---<drivers>

Inside the board_test folders are projects (e.g. .pjt files for CCSv3.3).  Both use files that are in the <algorithms> and <drivers> folders.  I think my options are

1.  Rename the <board_test> folders to something like <board_test_hw1> and <board_test_hw2>.  Do same for <customer_app1>. Have a single workspace located at root.

2. create a workspace called "target1_projects" whose top-level folder is <hw_target1>.  Create a 2nd workspace called "target2_projects whose top-level folder is <hw_target2>.

Which option would you recommend?  What are the trade-offs of each?

thanks,

Mike

I've got the same issue as Mike. But in my case, its the same project name but each project is targeting a different change request.

Cheers

Mike,

As I mentioned before to Eddie I usually have several workspaces for small projects, but what works for me may not work for everyone. I see fit for both approaches, though:

Mike said:

1.  Rename the <board_test> folders to something like <board_test_hw1> and <board_test_hw2>.  Do same for <customer_app1>. Have a single workspace located at root.

If all projects for the different products are located in the same workspace, then it is a lot easier to visualize the differences and even incorporate bug fixes across the different projects. As you said, something I got from working with Java is to try to give each project a qualified name: I usually use target product, type of hardware (or processor) and release. Something like productXYZ_rev1HW_1_0_5 or testbenchZYX_OMAPL138_2_0_3. This way all the projects for the productXYZ or to the testbenchZYX are shown aggregated in the workspace tree. Same thing for revision or processor used.

If your version control already adds some qualifier, then you should be ok to go - I use SVN and it does not.

Mike said:

2. create a workspace called "target1_projects" whose top-level folder is <hw_target1>.  Create a 2nd workspace called "target2_projects whose top-level folder is <hw_target2>.

The multiple workspace approach works better for me if confidentiality across customers is needed. In this case each customer would have its own working space that does a better job of preventing exchange of information. It also helps me concentrate in a smaller set of problems - it was not uncommon for me to jump to another project with a still ongoing issue while trying to try solve an issue on the current project... But that's just me. :)

I sometimes add an additional qualifier for ongoing developments (something like productXYZ_rev1HW_1_0_5_dev). This helps visualize what is released and what is not. This also helps with version control, since a "checked out" project will not have a name conflict.

Anyways, from the tool standpoint there is no difference between the two approches. I am a big fan of having fully qualified names (a liberation from the past where everything had to fit in 8.3 chars) and at the same time some projects demand having separated workspaces. A different approach may work better for your scenario.

Hope this helps,

Rafael

Thanks Rafael.  This is helpful input.  I agree with your approaches.  I found I can keep folders the same name and just have different project names.  So I think I'll go that route.  Then I can keep the same folder structure and just add additional info to the project name, something along the lines of what you suggest.  I had been using a convention where the project folder and project name were identical, but I found this isn't needed or important for CCSv4.

Mike