I am trying to create workspace into perforce so it will be available to other person who would like to add or submit file. I was following link which suggest to create new workspace
https://www.perforce.com/perforce/doc.current/manuals/p4v-gs/01_p4v-gs.html#1060773
I got one question, why perforce is looking into my local directory which can be deleted at any time.
The local directory that you mention is the root of the workspace. That's how Perforce knows where to put files when you tell it to get files from it.
You have a couple of options. One is to create a workspace and put /dev/null (or some other non-existent directory) and ask the eventual owner to change it before using the workspace. They should also change ownership to themselves. It is important that you don't "lock" the workspace when you create it, otherwise they won't be able to modify it, take ownership, or even use it.
Another option would be for you to create a workspace (for yourself), and then ask the other user to create a workspace, using yours as a template. The command line way is p4 client -t . Doing this via P4V, you would ask the user to find your workspace from the workspaces view, right click, and then from the contextual menu choose "Create/update Client using Clientname as Template..." (the wording might be slightly different, I don't have P4V open right now).
I recommend you go with option two. Doing so will automatically set ownership to the correct user, and the user will also be prompted to choose a local directory for the workspace root.
Related
I don't have admin privileges. Need to test other's change lists and submit them.
Tried changing the owner of the CL but didn't work without admin.
p4 change -U <creator> <CL>
Error in change specification.
Change <CL> can only be updated by user <creator>
Unshelving the original CL, then testing it, will create a duplicate CL. Duplicate CL is submittable but not the original CL.
Are there any ways to submit a perforce change list of another user without admin privileges?
Based on documentation I'd say no (see below). The way you are doing it is probably the best way using shelving. Another option would be to have an unstable branch that code is okay to be broken and another user can 'release' after testing to a stable branch.
From my understanding, changelists are owned by the user and not really "transferable" like you want.
From Helix 2020.2 documentation on the p4 change command
The owner of an empty pending changelist (that is, a pending changelist without any files in it) can transfer ownership of the changelist to another existing user either by editing this field, or by using the -U user option.
If you start down the "sharing a workspace" path. Don't. "It is actively discourages by Perforce Technical Support" and "it is almost never a good idea to share a Perforce client workspace among multiple users" https://community.perforce.com/s/article/3675
My question is:
I have downloaded all files before, then I switch to a new P4 Account, So I got a new workspace. But how can I use the file I have downloaded already with my new workspace? Do I need to redownload all files?
Multiple user accounts that are logged in on the same machine can use the same workspace. If you're using the same physical files, you should be using the same workspace rather than creating a new one which shares its Root.
If you have a copy of the files from the original workspace and want to use those to bootstrap the new workspace, you can do this with p4 flush and p4 clean. But you do not want to define multiple workspaces on the server that share the same physical Root on the client; this will never work well, just like you don't want to use multiple physical Roots with a single workspace definition. They should always be one-to-one.
The title may be misleading but I need to know more terms and more about P4V to properly summarize the question. That's also why I cannot get the answer by google.
I delete a workspace by mistake. Choose view->workspaces, and then the right pane list the workspaces I have. I delete one. And that's the one I have on another machine.
Files stay on the disk of that machine. But P4V do not show this workspace anymore. I plan to open a new connection, create a new workspace and set the same location. But I'm afraid that the sync operation will override the folder. That's not what I want. Because except from the source codes I get from depot, I have built the code. If overriden, a lot of build work has to be redone.
So, how to recover my workspace in perforce?
The situation is very similar to the one described in this KB article: http://answers.perforce.com/articles/KB/2446
After you have re-created the workspace, do not sync. As you say, it will overwrite your files (at least the read-only ones), and you don't want that.
Instead, open a command prompt and run:
p4 sync -k ...
p4 clean ...
The "p4 sync -k" tells the server to do a sync but keep what you have in your workspace instead of overwriting it. The "p4 clean" tells the server to verify what's in your workspace against what you just told it you have, and refresh any files that are different.
Do you happen to have a spec depot? Just view the client (you might have to "Show deleted depot files" if you don't already have that set up. If not, try to create a new one with the same settings (I'm hoping they were easy to remember). Do not sync the new workspace. Instead, do "p4 flush", details at p4 command info . This will make the server think you've synced to latest, but won't touch what you have on the workstation.
I've been reading about Perforce but haven't found any comprehensive explanation of relationship between workspace and working directory, e.g. how files appear in working directory from workspace, how they are tracked, what inconsistencies are possible between workspace files and working directory files etc.
I come from git background, and so I'm looking for the description of workspace and working directory interaction similar to index and working directory interaction in git.
For comprehensive information, the full Perforce documentation is available online. But here's a basic summary of the terms and concepts:
Perforce is a client-server system. The server tracks changes to files. Developers perform modifications to files using copies of those files on their machines, arrange those modifications into units called changelists, and submit those changelists to the server when they are ready.
All information about files is stored on the server. A client, or workspace, is a set of configuration data about a single copy of versioned files stored on a developer's workstation. For each workspace, the server keeps track of: which files are currently sync'd to that workspace, which pending changelists are being constructed, which user is using those files, in which directory on which computer the workspace resides, etc.
Getting a copy of versioned files into your workspace is called sync; submitting a new changelist with new file versions is called submit. As other users submit modifications of files, your workspace gradually becomes out of date; to bring it up to date you issue the sync command, possibly followed by the resolve command to merge newly-submitted changes to files you have been editing.
There isn't an exact analog of the git index construct. Modified files are copied from the developer's workspace on their workstation to the server by the submit command, and then are stored permanently in the server's archives. A somewhat different workflow is available in Perforce called a shelf. You can construct a changelist with modifications, and then use the shelve command to store that pending changelist on the server in shelved state. Pending and shelved changelists have several similarities to the way that git add allows you to assemble a commit prior to committing it, but there are also a number of differences, starting with the fact that Perforce tracks that information on the server, not in the client.
Perfore does not really have the concept of the "index/staging area" that Git does. Files only exist within the Perforce server (the depot) or in your local working directory.
The workspace is just a bundle of configuration data that tells Perforce what files to put where in your local environment.
It is effectively a "binding" that specifies what files to select from the depot and where to place them in your working directory. This flexibility can be incredibly useful in some circumstances, but it is also an extra level of indirection compared to other VCS's such as Git/Mercurial/Subversion.
If you look at the contents of a workspace definition you will see a "Root:" section that points to a location on your local machine, and a "View:" section that tells Perforce what files you want synced to that location.
The Perforce documentation is a bit confusing with regards to its terminology. In the docs I've seen, "Workspace" refers to BOTH the specific workspace definition that you create (which is a data structure held within the Perforce server) AND the local working directory that the workspace is bound to, fairly interchangably. This is because the whole point of a workspace is to bind to a specific local working directory.
Take a look at example 15 here: Managing files and changelists
The output of the p4 sync command shows that it is writing files to the C: drive. When you "retrieve files from the depot into your client workspace" that DOES actually mean that files get copied into your local working directory.
Let's take a workspace definition for example. The key fields for this explanation are Client, Root, and View, so I'll only show those for clarity:
Client: mysimpleclient
Root: /Users/johndough/myspecialproject
View:
//depot/foo/... //mysimpleclient/...
The Client field defines the name of the workspace. The Root field defines the root of the workspace on the local filesystem. The View field describes how files from the server will be mapped to your workspace files. (This adds some flexibility when compared to Git, but at the cost of a bit of a learning curve). I've used a very simple mapping here, but this could be a lot more complex.
Let's break down the View field. Let's say the server has a file //depot/foo/bar.txt.
When you sync (get latest revision) of this file, Perforce will use the view line to determine where the file lands on your filesystem.
Here is our view again:
//depot/foo/... //mysimpleclient/...
The left side is in depot syntax, the right side is in workspace syntax, and it always starts with //workspace_name. The "..." is a recursive wildcard (kind of like ** with globbing). You can mentally replace the workspace name with the value of the root, to make sense of this.
Remember our root is: /Users/johndough/myspecialproject
So, after replacing "//mysimpleclient" with that value we arrive to:
//depot/foo/... /Users/johndough/myspecialproject/...
Let's use that modified view line to figure out where bar.txt will end up:
//depot/foo/bar.txt /Users/johndough/myspecialproject/bar.txt
This is how it works when you pull files down. When you add new files, the mapping is read in reverse. Let's say you create a file /Users/johndough/myspecialproject/fred/file.txt
Our (mentally modified) view is:
//depot/foo/... /Users/johndough/myspecialproject/...
We interpret this in reverse. Concatenate the relative path of the new file with the root of the workspace:
/Users/johndough/myspecialproject/fred/file.txt
And then do the same for the left side:
//depot/foo/fred/file.txt
Putting it altogether:
//depot/foo/fred/file.txt /Users/johndough/myspecialproject/fred/file.txt
Hopefully this helps. The notion of workspaces is probably the most difficult aspect of getting started with Perforce. Happy coding!
I'm in charge of creating a TFS instance that will be used for, among other things, source control. The source control directory structure needs to mirror another directory, and as such I need to be able to allow users to add, remove, and edit files anywhere within the source control space, but not be able to create new folders, or alter the directory structure in any way (I've already solved the problem of synching source control to the other directory).
My question is, is it possible to map my TFS project to a public workspace, lockdown permissions to that workspace so that users can only use it to manage files, and not the directory structure, and also configure it so that users cannot create a local workspace (or, at the least, cannot publish/shelve) changes from that local workspace?