Jump to content


Null directory (//) not allowed

Null directory (//) ChangeView

  • Please log in to reply
7 replies to this topic

#1 PeterB

PeterB

    Newbie

  • Members
  • Pip
  • 3 posts

Posted 11 September 2017 - 02:38 AM

Error: Null directory (//) not allowed. Some background and details follow.

I finally got Perforce to work. Two problems when taken together made my life difficult for a few days: My inexperience with perforce and the dregs leftover from a previous install.

All Perforce s/w is latest version d/l in last few days.

Before asking for help I read the docs and check with Google. Both multiple times.

I like my working files all in one directory. Yet at the same time I want a structured depot. Thus my workspace view looks like this:

//depot/*   //Lamp/*

+//depot/RTOS/*.*   //Lamp/*.*

+//depot/RTOS/inc/*.*   //Lamp/*.*

+//depot/RTOS/M0specific/*.*    //Lamp/*.*

etc…


Likely my inexperience shows because I get errors on the first line: Error at line 1 of field ‘ChangeView’ in client specification. Null directory (//) not allowed in ‘//depot* //Lamp.*’

Yet it fixed itself at night(?) Good, I thought, it’s working now. Alas, it only worked once.

I tried using downlevel p4v. Did not help. Reboot server machine. Went back. Bad stuff happened. On the second p4v reinstall I was back to where I was before.

So . . . How do I set my workspace view without making errors?

FWIW, Win7 Server, Win10 laptop same problem on both

#2 P4Reg

P4Reg

    Advanced Member

  • Staff Moderators
  • 98 posts

Posted 11 September 2017 - 09:18 AM

The Perforce syntax to mean "all files under this depot path" is  "..."

//depot/...   //Lamp/...


See the "Configure workspace views" section in the P4 Command reference: https://www.perforce...space_view.html

#3 P4Reg

P4Reg

    Advanced Member

  • Staff Moderators
  • 98 posts

Posted 11 September 2017 - 09:22 AM

Also, while using //depot/* is a valid syntax, it only applies to files and folders in a single directory

See "Use wildcards in workspace views":

https://www.perforce....wildcards.html

#4 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 927 posts

Posted 11 September 2017 - 02:17 PM

View PostPeterB, on 11 September 2017 - 02:38 AM, said:

Likely my inexperience shows because I get errors on the first line: Error at line 1 of field ‘ChangeView’ in client specification. Null directory (//) not allowed in ‘//depot* //Lamp.*’

Sounds like you mixed up the "View" and "ChangeView" fields.  (The error is because ChangeView is a single path, and you can't have a "//' embedded in a path.)  For what you're doing you want to be using the "View" field -- leave the "ChangeView" field blank.

I feel obligated to warn you that the thing you're trying with the overlay mappings is going to lead to a lot of suffering.  I'd encourage you to share more information about how you envision this scheme working and how your depot is laid out; somebody on this forum will probably be able to think of a better way to accomplish something similar.

#5 PeterB

PeterB

    Newbie

  • Members
  • Pip
  • 3 posts

Posted 11 September 2017 - 06:26 PM

View PostSambwise, on 11 September 2017 - 02:17 PM, said:

Sounds like you mixed up the "View" and "ChangeView" fields.

That was my problem. It works now. THANK YOU!

I'm not doing overlay mapping at least as I understand the words. What I am doing from OP is: "I like my working files all in one directory. Yet at the same time I want a structured depot." Many files are common to multiple Cortex-M series RTOS versions. Updates in one processor core version often apply to other versions. Processor vendor specific (ST, TI, NXT...) mods do much the same thing.

#6 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 927 posts

Posted 11 September 2017 - 07:01 PM

The "+" symbols in your View indicate an "overlay mapping", aka (speaking as one who has helped many people untangle these things) "a one-way ticket on the pain train".  Don't say nobody warned you!  The big gotchas to watch out for:

1) When files in any of those directories have the same name, the higher precedence (last in the mapping) wins, even if it's a deleted file.
2) When you add a new file, higher precedence wins unless you specify a lower precedence depot file for the add operation.  I forget how good P4V is at handling this (it used to not do it at all but I think that got fixed with some sort of popup dialog that asks you to pick an option, in which case I guess you'll be getting prompted on every single file you add, yuck).  From the command line you can do it by providing a fully qualified depot path to "p4 add".  Due to (1) you only get one shot at doing this right!
3) It will not be obvious when looking at your local tree how everything maps back to the depot, so if any of this stuff gets mixed up, it could easily go undetected for a while and then cause an inexplicable failure down the line.  Consider this carefully when setting up testing and build processes.

As a separate thing, I recommend replacing that *.* with just * unless you are very deliberately trying to exclude files that don't have a . in their name. Double wildcards are a performance time bomb and should be avoided if there's no real need for them.

FWIW if I had to arrange my workspace like this (and I would try to avoid that in the first place, i.e. keep things structured in the workspace as they are in the depot and put the dependency information in the build/dev tools) I would be encoding all this information in a stream definition or a template client rather than relying on overlay mappings to smush everything together and hope it all works.

#7 PeterB

PeterB

    Newbie

  • Members
  • Pip
  • 3 posts

Posted 13 September 2017 - 06:22 PM

Assume my depot is setup like this:

Proj1/

  Files/

    Random.cpp

  More/

    stuff

Proj2/

  Files/

    Random.cpp

  More/

    stuff

Misc/

  One/

    Sync.bat

  Two/

    Sync.bat


And Perforce views:

Workspace One is for ARM  


//depot/.    //One/.

+//depot/Proj1/Files/.  //One/.

+//depot/Proj1/More/.   //One/.

+//depot/Misc/One/. //One/.


Workspace Two is for x64


//depot/.         //Two/.

+//depot/Files/Proj2/.  //Two/.

+//depot/Proj2/More/.   //Two/.

+//depot/Misc/Two/. //Two/.


It sounds like Sambwise is saying that I could get into trouble easily. Does Perforce get confused with “Files”, “Misc” or “More”?

He mentioned stream. Would using stream eliminate the problem? I.e. just check stream “and away go troubles…”.

I really want to end up with what I call a flat directory structure in my workspace root. Perhaps later I will put header files in WorkspaceRoot/h but (I’m guessing here) that’s an easy change to the overlay structure: //One/h/.

As mentioned in a previous post I structured the depot to exploit the commonality of the various files I am working with. I.e. same headers for ARM and x64. And for each unique workspace a sync.bat.

FWIW, I wrote a perl script that assisted in obliterating all deleted files. Then extended it to do the same with all downlevel files. Still had problems.

I would greatly appreciate any hints, sample workspace fragments or web pages that lead me away from trouble.

#8 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 927 posts

Posted 13 September 2017 - 07:05 PM

Since there's no overlap between projects/architectures in this example (there are no files at the root of the depot, right?) it might not be a good one to work with, since you mentioned needing to share some changes between projects -- but I'll ignore that for now and work with what we've got.  :)

If you're looking to be led away from trouble, here's my suggested workspace setup:

//depot/Proj1/... //One/Proj/...
//depot/Misc/One/... //One/Misc/...

//depot/Proj2/... //Two/Proj/...
//depot/Misc/Two/... //Two/Misc/...

This is a nice clean one-to-one mapping.  Given any path, in complete isolation, it's completely trivial to figure out how the depot<-> workspace mapping works.  It's very clear which files are "Proj" files and which are "Misc"; you're never going to end up with files that are supposed to be in one depot directory accidentally ending up in the other.

Now, if you want to try to "flatten" things without necessarily using overlay mappings (my opinion is that the hassle involved in flattening your workspace like this is going to far outweigh the time you save by not having to "cd" to different directories, but it's a fun exercise), given the files in your example, I might differentiate by extension, like this:

//depot/Proj1/More/... //One/...
//depot/Proj1/Files/....cpp //One/....cpp
//depot/Misc/Proj1/....bat //One/....bat

That is -- any .cpp files in your workspace go in Proj1/Files, any .bat files go in MIsc/Proj1, and anything else goes in Proj1/More (since I don't know what extensions live in there).  This is a slightly more complicated set of rules but it at least has the advantage of being completely deterministic given only a path, rather than depending on what's in other directories and requiring you to do regular obliterates just to keep things straight (if you need to obliterate as a regular part of your development workflow, it's a big flashing neon sign that something is very wrong).

With either of these examples, the benefit of streams is that if you end up having to define a really complicated view (because you have hundreds of directories to deal with), defining it as a stream instead of a client makes it so that you can easily generate other clients without having to copy the entire view.





Also tagged with one or more of these keywords: Null directory (//), ChangeView

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users