Re: [p4] Null directory (//) not allowed

Posted on behalf of forum user 'Sambwise'.

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.



--
Please click here to see the post in its original format:
  http://forums.perforce.com/index.php?/topic/5477-null-directory-not-allowed
_______________________________________________
perforce-user mailing list  -  [email protected]
http://maillist.perforce.com/mailman/listinfo/perforce-user