Author Topic: Maybe a simple question on Workspaces/Projects  (Read 691 times)

Ryan0751

  • Community Member
  • Posts: 24
  • Hero Points: 1
Maybe a simple question on Workspaces/Projects
« on: November 14, 2013, 09:46:54 pm »
For most of my SlickEdit experience, I have always created a new workspace and project for each code version I'm working on.  If I have a 1.0, I create that workspace/project, 1.1, I create a separate one.

If these are all the same product, does it work to create one workspace and then have multiple projects under that, for each version?  Was that the intent or am I confusing things?

I should add that I'm using Perforce, and each of these version exists as a separate Perforce client.

chrisant

  • Senior Community Member
  • Posts: 1413
  • Hero Points: 130
Re: Maybe a simple question on Workspaces/Projects
« Reply #1 on: November 15, 2013, 02:36:14 am »
Whether it "works" depends on your needs.

The tag file is shared across the workspace, so there may be confusion when looking up symbols or references.
Also there may be confusion when using the smart open command, as it sorts (by default at least) by the file name (so 8 versions of "foo.cpp" will be clustered together, then 8 versions of "goo.cpp", etc).

I use separate workspaces for different versions.  I haven't been able to think of any benefits I'd get from putting all versions into one workspace, though I've found many drawbacks (the two above for starters).

Ryan0751

  • Community Member
  • Posts: 24
  • Hero Points: 1
Re: Maybe a simple question on Workspaces/Projects
« Reply #2 on: November 15, 2013, 11:02:04 am »
Oh hmm, same tag and smart open would NOT work for me.

What is the purpose of multiple projects in that case?

chrisant

  • Senior Community Member
  • Posts: 1413
  • Hero Points: 130
Re: Maybe a simple question on Workspaces/Projects
« Reply #3 on: November 15, 2013, 06:20:41 pm »
Projects are subsets of files.  If you want subsets of files for whatever reason, projects are a way to accomplish that.

The build/compile/debug settings are per-project.  So if different parts of a code base need different settings for those, then using projects is probably necessary in that workspace.  I've never worked with a code base that had different build systems for different pieces of it, though.

Maybe a code base uses some third party libraries, and maybe for organizational purposes you put those in separate project(s) from the main code base.

You can scope some things to specific projects (search, maybe references, other things I forget), but personally the scoping is too cumbersome for me, I never use it.

Probably a bunch of other reasons, too.  I expect the reasons tend to be nuanced and typically aren't functionally significant.