How do I shorten a clearcase view's load directory?

In Clearcase I have a VOB with a path like this:

\Department\ProductGroup\Product1\Development

I have a view with a Config Spec like this:

element * CHECKEDOUT
element * .../mybranch/LATEST
element * /main/LATEST -mkbranch mybranch
load \Department\ProductGroup\Product1

All the source code for Product1 is in the Development directory. Nothing I care about exists outside this directory. All references in the code are relative to this directory.

I have created the above Clearcase view in the directory c:\dev

Presently the above setup creates a directory:

c:\dev\Department\ProductGroup\Product1\Development

All the parent directories to Development are empty. I'd rather have just the following directories.

c:\dev\Product1

Where c:\dev\Product1 mapped to the VOB path \Department\ProductGroup\Product1\Development. Is this possible?

From stackoverflow

• 1/ Why not only load \Department\ProductGroup\Product1\Development ?

  load /Department/ProductGroup/Product1/Development
  

  Note: you can use '/', easier than '\' and Windows config spec does interpret it correctly.

  1bis/ If you want to keep a general rule, you could use some "cleaning rules"

  Consider this config spec
  (test it in a dynamic view first, to check quickly -- that is without endless update reloading steps -- if the result does match what you need: files under Development and no files anywhere else)

  element * CHECKEDOUT
  
  # read/write selection rule for the directory and sub-directory
  # where you need to work
  element /Department/ProductGroup/Development/... .../mybranch/LATEST
  element /Department/ProductGroup/Development/... /main/LATEST -mkbranch mybranch
  
  # specific selection rule for the parent directories of Development
  # those rules do not contain a mkbranch directive
  element /Department/ProductGroup  .../mybranch/LATEST
  element /Department/ProductGroup /main/LATEST
  element /Department  .../mybranch/LATEST
  element /Department /main/LATEST
  
  # cleaning rule right there: anything outside /Department/ProductGroup/Development
  # will not be selected, hence not loaded
  element /Department/* -none
  
  load \Department
  

  That way, you always keep the same load rule load \Department, and your selection rules do the cleaning for you.

  2/ Regarding your path issue, you can use Symlink but the easiest way is to use a subst

  subst X: c:\dev\Department\ProductGroup\Product1\Development
  

  And you could go on using your snapshot view within X:\

  BUT that would not work because ClearCase needs:

  • view.dat (the hidden file indicating a directory tree is in fact a snapshot view)

  • a vob (which is Department in your case. ProductGroup\Product1\Development is a path within the Vob Department)

    X:>ct lsview -l -full -pro -cview cleartool: Error: Cannot get view info for current view: not a ClearCase object. X:>ct ls cleartool: Error: Pathname is not within a VOB: "."

  For those same reasons, a hardlink with Junction on windows will not work:

  c:\dev>junction Product1 Department\ProductGroup\Product1
  Junction v1.05 - Windows junction creator and reparse point viewer
  Copyright (C) 2000-2007 Mark Russinovich
  Systems Internals - http://www.sysinternals.com
  
  Created: C:\dev\Product1
  Targetted at: C:\dev\Department\ProductGroup\Product1
  
  C:\cc\xxx>ct ls
  cleartool: Error: Pathname is not within a VOB: "."
  

  So what you can do is:

  subst X: c:\dev
  

  That combined with the specific load rules from 1/ or the cleaning rules from 1bis/ will give you:

  • a slightly shorter path
  • no extra empty sub-directories

  ---

  2bis/ "Devious" solution:

  From the ClearCase explorer, move Development from Department\ProductGroup\Product1 to Department! That move will be recording within 'mybranch' version tree, and will not be visible for anyone else working in /main/LATEST.

  Then with the subst from above, you will work within 'mybranch' in Department\Development.

  X:\Department\Development
  

  When you want to go public, make the inverse move.

  orj : Thanks for all the info but from your description the key problem of long paths only appears to be "solvable" by using subst.

  VonC : NO: a move of the directory within a dev branch is a good workaround