Using a single project across multiple branches

[sshanson]

I'm using SlickEdit v 11.0.1.
I've created a Workspace and Project for my source tree, but I want to be able to use the same project across multiple branches. For example, I usually work within our main branch; let's call this /main. Inside /main are multiple source directories. I have a Main workspace with a Source project file containing all the source files et al inside /main/... .

This is great, except sometimes I work on a private branch. Let's call this /private. /private also has a copy of the same source tree.

Now what I want to do is use the same Source project, except I want it to reference the files inside /private instead of /main.

How do I do this?

I thought I could create two Workspaces and set an Environment variable in each of them pointing to the root of the tree - The Main workspace would set ROOT=/main and the Private workspace would set ROOT=/private. Then if both Workspaces used the same Source project I would only have one project file to maintain. But this doesn't seem to be the right way to go as I can't use the %ROOT% env variable to add files to the project.

Any ideas on how I can do this? Or am I stuck having to maintain two sets of almost-identical projects for my two branches?

[Dennis]

Depending on what version control system you are using, you might want to consider checking the .vpw and .vpj files in.  This way the workspace/project exists relative to the source directory and you don't have to modify paths, and you can version the workspace/project along the same branching scheme you use with your source code.

The one caveat is that if you are using ClearCase with views, this may not be a terrific solution, since you may experience performance problems having your workspace (and workspace tag file) under the ClearCase virtual file system which doesn't perform quite as well as a native file system.  The workaround we recommend is to check your project files into ClearCase, but keep the workspace outside of Clearcase, which isn't too bad to maintain since the .vpw file just points to your project files.

We also recommend this workaround for people who keep their source trees on remote files systems, or any other file system that has noticable performance limitations.

[jbezem]

Dennis' answer doesn't quite fit the question as I understand it.
The *.vpw workspace files contain relative paths to the projects included, based on the workspace directory.
Also the *.vpj project files contain relative paths to the source files, based on the project directory. No problem so far.
Only one problem I see: At least in my current workspace/project (using version 11.0.2, but the project was created in version 10.0.x, using dtd/vse/10.0/vpj.dtd) the project include directories have been entered in the *.vpj files using absolute paths.
AFAICT only these prevent me from reusing the same *.vpw/*.vpj files in a second, identical copy of my project's structure.

Any chance that I/we can enter include directories using project-relative paths? As well as absolute ones, of course, since my compiler installation and my libraries will not move with my project's instance.
For now, I can do a 'replace' on the *.vpj files and reuse them in such a way, but that's tedious. And I cannot use links on Unix...

BTW, ClearCase is not a problem unless you use 'dynamic views', as they are called IIRC.
And BTW2: Checking-in *.vpw/*.vpj files is only possible if all SlickEdit users within the project use the same workspace/project conventions. In my experience that is seldom the case, since many developers routinely use a restricted workspace to limit the amount of tagged source files. And I myself always complain when people check in backup files, Eclipse settings or directory descriptions using some tool or other ;-)

FWIW,

Johan

[RobFreundlich]

I have a similar situation.  The solution I've come up with (Windows only) is to use SUBST to keep a specific drive letter pointing to the root of my current branch.  So, in your example, I'd SUBST Y: c:\dev\main, and then create my project from y: rather than from c:\dev\main.

When I create a new branch, I copy the .vp* files to the new branch's directory.  Then all I have to do is re-subst y:, and my project works fine in the new branch.  Actually, now that I think about it, I also rename them to match the branch name, so I also have to do a bit of search-and-replace to make sure all of the references (such as the .vpw file referencing the .vpj file) are OK.

I've got a CMD script that looks like this:

Code: [Select]

subst y: /d

REM --- old version ---
REM subst y: c:\dev\priorVersion\code

REM --- main ---
subst y: c:\dev\main\code

REM --- private ---
REM subst y: c:\dev\private\code

echo done
exit

I have a shortcut to the script in my startup directory.  When I want to switch branches, I edit it to comment out the current branch and uncomment the one I want to work on, and then run the script.

By the way, if you need to have multiple run-time copies of your product (one per branch), this works well too.  I keep z: SUBST'd to c:\dev\BRANCH\install using the same script.  So running my switcher script also switches my runtime testing environment.

[Dennis]

FYI, the include paths can be relative -- just type them in that way.  Also, you can use %rp in the include paths to represent the project directory or %wp to represent the workspace directory.

[framos]

FYI, the include paths can be relative -- just type them in that way.  Also, you can use %rp in the include paths to represent the project directory or %wp to represent the workspace directory.

Is there a document (either on the web or included with the product) where all those % macros are documented? I remember seeing one but I can not find it anymore...

[Dennis]

help _parse_project_command