I have setup a new Perforce server via docker. I have an admin user and I can connect to it successfully.
It is of course an empty server, so I created a new workspace called foo with the following view:
//depot/... //foo/depot/...
Adding any new file fails in:
/Users/test/workspace_foo/file - file(s) not in client view.
I found this problem hundreds of times, but I am beyond the step of missing to create a workspace view, still it does not work. Any idea what I am missing here?
I struggled hard on this. And I'm not sure if I finally understood the real cause why it's working now.
To me, it looks like you need to create the mapping with the three dots as expression in order to be able to create a more specific one.
Example Here
However, after I added the 'three-dot-mapping' I could finally add all my files without any trouble. What doubts me a little is that after I opened the Mapping again, my 'three-dot-mapping' disappeared, and it just showed me a mapping to the folder I added.
As I understood, you need the
//depot/... <-> /Users/test/workspace_foo/...
mapping in order to be able to create a
//depot/anotherFolder <-> /Users/test/workspace_foo/anotherFolder
mapping. Also make sure, that first you add a file / folder directly under /Users/test/workspace_foo/....
If anyone has further explanations for this, I look forward hearing them.
I'm going to assume that your workspace's root is /Users/test/workspace_foo. That's what //foo in your client view corresponds to:
Client: foo
Root: /Users/test/workspace_foo
View:
//depot/... //foo/depot/...
right? So that means that:
//depot/... <-> /Users/test/workspace_foo/depot/...
Sidebar: The p4 where command will show you the depot-syntax, client-syntax, and local-syntax version of any given path; use p4 where //... to see your entire client mapping with overlapping view entries disambiguated and client paths expanded to local syntax.
The local file you're trying to add is not within the local path of the client view you've defined, which is why you're getting the error file(s) not in client view. If you want to leave your view mapping the way it is, you'll need to move file into a path under /Users/test/workspace_foo/depot in order to be able to add it. Whatever path you create on the client relative to /Users/test/workspace_foo/depot will be created on the server relative to //depot.
If you want /Users/test/workspace_foo/file to map to //depot/file, then change your View like this:
Client: foo
Root: /Users/test/workspace_foo
View:
//depot/... //foo/...
which means that:
//depot/... <-> /Users/test/workspace_foo/...
and therefore:
/Users/test/workspace_foo/file <-> //depot/file
Related
I have created a Perforce workspace definition with which I will be able to "run the latest demo" on a PC.
Then I wanted to try and check out the same workspace on another PC in order to run the same demo. I found that I could not do this because the workspace is somehow tied to the first PC where I created it.
I ended up copying the workspace by
inspecting the textual definition of the workspace and copying it to a text editor,
searching and replacing "WantedWorkspaceName" with "WantedWorkspaceName_NewHostname",
creating a new workspace with a new name ("WantedWorkspaceName_NewHostname"),
giving the new workspace the same workspace root path ("D:\Demo") as the original workspace,
pasting the modified textual representation into the textual representation of the new workspace.
Surely there must be a better way to achieve what I want? (Use the same workspace mapping on different hosts.)
Just use the -t template option to p4 client:
p4 client -t WantedWorkspaceName WantedWorkspaceName_NewHostname
You may also want to look at streams, which are an alternative way of setting up client/branch mappings. Rather than configuring each client individually, you define a single "stream" which encapsulates a set of depot mappings and branching relationships to other streams. Then a client can be defined simply in terms of what stream it's associated with, and the views are auto-generated whenever the stream is changed.
Typically, we have a depot root for every different product that we work on. For e.g.:
//products/productX
/productY
As the common files in the 2 products increase, I would like to put them into a top level folder of it's own
//products/productX
/productY
/common
Now to ensure that this works for all the users who have existing workspace, we would need to update all their workspaces. Is there an alternative? Can we put some markers in the depot to create a link it to a different folder? Any other option?
What you're describing is essentially the reason that streams were created -- the idea of a stream is that you definition the structure of a codeline in one place (e.g. "product X lives in //products/productX"), multiple people base their workspaces on that, and when you change it (e.g. "product X lives in //products/productX + //products/common), every workspace based on that definition updates automatically.
So if you're using streams, all you need to do is update the stream definitions that need to include the new //products/common directory. Easy!
If you're using "classic" workspaces, users who are using the default //products/... mapping will get the common directory automatically regardless. For users with custom views, my suggestion would be to alert them of the refactor and then let them make their own adjustments as appropriate; if they're familiar enough with Perforce to have built a custom client view, they may not appreciate having it changed underneath them.
i was hoping someone could point me in the right direction? I am trying to set up a second depot, but whenever i try adding files it will spit out this message ' not in client view'.
The primary depot is up and running fine for a unreal project, but i can't figure out how to set up a second one. I made sure to exclude the primary depot tree when creating a new workspace and also made sure to point it to the correct workspace directory.
Your client view defines which depot files are mapped to your workspace, and where they're mapped to. If your client view looks like:
Root: C:\Perforce
View:
//apples/... //your-client/apples/...
//pears/... //your-client/pears/...
both the apples and pears depots are mapped to your workspace as follows:
//apples -> C:\Perforce\apples
//pears -> C:\Perforce\pears
If you try to add a local file that is not in either of those locations, you will get an error:
C:\Perforce>p4 add gravenstein.jpg
gravenstein.jpg - file(s) not in client view.
This is because according to your View, that file doesn't belong in either depot. You need to put the file in a location that you've mapped so that Perforce can figure out which depot (and which directory) it goes in.
C:\Perforce>move gravenstein.jpg apples
1 file(s) moved.
C:\Perforce>p4 add apples\gravenstein.jpg
//apples/gravenstein.jpg#1 - opened for add
In your comment, you mentioned removing "the extra part". Suppose you changed your View to look like:
Root: C:\Perforce
View:
//apples/... //your-client/apples/...
//pears/... //your-client/...
Now your client root maps directly to the pears depot, and the apples depot is no longer mapped anywhere!
C:\Perforce>p4 add pippin.jpg
//pears/pippin.jpg#1 - opened for add
C:\Perforce>p4 add apples\honeycrisp.jpg
//pears/apples/honeycrisp.jpg#1 - opened for add
This is because later lines always take precedence. By flipping the order of the View lines you can make it so that most of the workspace is mapped to pears, but there's an exception for the local apples directory:
View:
//pears/... //your-client/...
//apples/... //your-client/apples/...
C:\Perforce>p4 add bartlett.jpg
//pears/bartlett.jpg#1 - opened for add
C:\Perforce>p4 add apples\granny_smith.jpg
//apples/granny_smith.jpg#1 - opened for add
However, I'd usually recommend that parallel depot paths (e.g. two top-level depots) be represented by two parallel local directories (the default) rather than nesting them inside each other -- it makes it easier to reason about what file goes where if the depot and the workspace mirror each other as much as possible. Just remember that you need to put local files in the directory that goes with the depot you want to add them to.
Maybe some Perforce gurus could provide some advice.
We have a depot, with a setting.xml file in central folder:
///depot/central/config/setting.xml
and would like it to be instanced in several locations, like:
///depot/projectA/tool1/config/setting.xml
///depot/customerB/tool2/config/setting.xml
The benefit is for maintenance. the setting.xml file only has to be updated once in //depot/central, then all files in the other places get updated as well, so we don't have to get into each place, duplicate it again and again.
AlienBrain has a feature called 'shortcuts', does Perforce have something similar?
We've tried use the OS' symbolic links feature, but it didn't behave the way expected -- cloned files still need to be checked-out first, then check them in again -- this makes the cloned files own their own revisions against the original one.
It's better to just keep the original and cloned files have the same revisions. so if submitting a new revision to setting.xml(5/5)(which makes it to be setting.xml(6/6)), the cloned files as this point still remains setting.xml(5/6). Thus, people on projectA & customerB can simply sync to the latest version.
Thanks.
You can use the Perforce client spec to map files from the depot into your workspaces, which should do almost exactly what you're looking for.
For example, your client spec for tool 1 would be something like:
//depot/projectA/tool1/... //workspace_for_tool1/...
//depot/central/config/setting.xml //workspace_for_tool1/config/setting.xml
And your client spec for tool 2 would be something like:
//depot/customerB/tool2/... //workspace_for_tool2/...
//depot/central/config/setting.xml //workspace_for_tool2/config/setting.xml
The main downside of this approach is that you need to make this change in every client spec, and you need some infrastructure dedicated to propagating client specs to new workspaces.
So I'm new to XUL.
As a language it seems easy enough and I'm already pretty handy at javascript, but the thing I can't wrap my mind around is the way you access resources from manifest files or from xul files. So I did the 'Getting started with XULRunner' tutorial... https://developer.mozilla.org/en/getting_started_with_xulrunner
and I'm more confused than ever... so I'm hoping someone can set me straight.
Here is why... (you may want to open the tutorial for this).
The manifest file, the prefs.js and the xul file all refer to a package called 'myapp', that if everything I've read thus far on MDN can be trusted means that inside the chrome directory there must be either a jar file or directory called myapp, but there is neither. The root directory of the whole app is called myapp, but I called mine something completely different and it still worked.
When I placed the content folder, inside another folder called 'foo', and changed all references to 'myapp' to 'foo', thus I thought creating a 'foo' package, a popup informed me that it couldn't find 'chrome://foo/content/main.xul', though that's exactly where it was.
Also in the xul file it links to a stylesheet inside 'chrome://global/skin/' which doesn't exist. Yet something is overriding any inline styling I try to do to the button. And when I create a css file and point the url to it, the program doesn't even run.
Can someone please explain what strange magic is going on here... I'm very confused.
When you register a content folder in a chrome.manifest you must use the following format:
content packagename uri/to/files/ [flags]
The uri/to/files/ may be absolute or relative to the location of the manifest. That is, it doesn't matter what the name of the containing folder is relative to your package name; the point is to tell chrome how to resolve URIs of the following form:
chrome://packagename/content/...
The packagename simply creates a mapping to the location of the files on disk (wherever that may be).
The chrome protocol defines a logical package structure, it simply maps one URL to another. The structure on disk might be entirely different and the files might not even be located on disk. When the protocol handler encounters an address like chrome://foo/content/main.xul it checks: "Do we have a manifest entry somewhere that defines the content mapping for package foo?" And if it then finds content foobar file:///something/ - it doesn't care whether that URL refers to a file, it simply resolves main.xul relatively to file:///something/ which results in file:///something/main.xul. So file:///something/browser.xul will be the URL from which the data will be read in the end - but you could also map a chrome package to another chrome URL, a jar URL or something else (theoretically you could even use http but that is forbidden for security reasons).
If you look into the Firefox/XULRunner directory you will see another chrome.manifest there (in Firefox 4/5 it is located inside omni.jar file). That's where the mappings for global package are defined for example.