We have 30 User's and 26 of them are Artists, and all of their workspaces were created manually with their username and a project alias. Now we want to add some new view's to the user's workspace, is there a way to do a bulk-edit on that with a perforce command?
Can I, as an admin modify a workspaces view and that would be reflected, next time the Artist opens up perforce?
Perforce's built-in solution for this is called streams.
With a "stream-based" workflow, each project (and each codeline for each project, if applicable) is defined by a "stream" specification that defines which paths the project contains, and its relation to other streams, if any.
When a workspace is associated with a stream, the view is automatically generated based on the stream specification, and modifications to the stream specification are automatically propagated to all workspaces associated with that stream.
With a "classic" client specification, each workspace has its own independently created view, which is not tied to any other workspace or any other object. As an admin you can modify an other user's client spec via the p4 client -f command, and you could potentially script this command to automate that modification across multiple client specs.
However, I'd recommend looking at streams as an easier solution; it might be a bit of work up front to migrate from manual views to stream views, but if you anticipate the need to make changes like this frequently, using streams will be quite a bit easier than maintaining your own tooling.
Related
So I've been reading the helix-core documentation for the p4 command line tool because I cannot use the visual client on my current machine. I am trying to get a way to get the latest files from the local depot on the server, which stores the project me and my team are working on.
I have found the sync command but it requires a stream. I never had to define one when I set up the visual clients for the team or the server if I recall correctly and so if I had one I couldn't find it. The administration tool only shows me the depot like this: //depot/myFiles, which is the default local depot that is created when the server is created if I'm not mistaken. So I've been wondering if it's possible to just "get latest" like in the visual client without a stream or how I can find the stream this depot is using.
tl;dr: the thing you want to make is a "workspace", not a "stream". Run p4 client to create a workspace.
Depots come in two basic flavors in Perforce: stream and local (aka "classic"). The type of a depot is set when it's created by the Perforce admin. One server can have any number of depots.
In a stream depot, files are organized into streams, which by default take the form of top-level depot directories, e.g. //stream/main and //stream/rel1. Streams can be configured to represent files beyond what's in the actual depot directories, but in their simplest form each stream just corresponds exactly to a directory in the depot, including one mainline stream and usually many other streams that are branched from the mainline. Every file in a stream depot is inside a stream. You can run the p4 streams command to see a list of all the streams.
In a local depot, there are no streams. You can add any file anywhere. Usually files are organized into parallel top level directories that are branched from each other, e.g. //local/main and //local/rel1, but there are no guard rails that steer you toward this.
In any kind of depot, you need to create a client workspace to sync and submit files. Each workspace has a client view which creates a mapping between depot files and workspace files; the client view takes depot files and puts them into your workspace when you sync, and it takes workspace files and puts them into the depot when you submit. Each workspace is unique to a particular directory on a particular client machine (the client root) -- you must create a new workspace for each local machine you do work on!
In a stream depot, when you create a workspace, you specify the Stream that you're going to work on. A client view is generated for you automatically that maps your workspace root to the files in the stream. You are not allowed to modify this view manually; if you want to change the view, you need to change the stream, and this will automatically update the views of all clients associated with that stream (so one stream may have many clients, but they will always share a consistent view -- the main function of streams is to centralize client view management).
In a local depot, when you create a workspace, you define a View yourself. By default, when you create a workspace on a server that has a single local depot, the client view maps the entire depot to the workspace root. You can edit the View yourself to map arbitrary paths in the depot to arbitrary paths within your workspace, so you have complete control over which depot files you sync and where each one goes.
To create a client workspace from the command line, run:
p4 client
This will open an editor that contains the client spec. Edit the Stream or View field appropriately. Note that the default name of the client workspace is the hostname of your client machine that it lives on; if you want to change this, run p4 set P4CLIENT=your-client-name before running p4 client. Save the client spec, exit the editor, and you'll see a message like "client saved".
Now you can sync:
p4 sync
This will use your current client spec (the one you've just defined) to sync files from the depot into your workspace. You only need to create the client spec the first time you set up a new client machine, but you can run p4 client again at any time to modify it.
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 am new to Accurev. I am working on a workspace and I see a problem which I need help from a team member to look at the issue. what is the easiest way to let the other team member to access my files in my workspace through Accurev?
Using Subversion, anyone could checkout my branch and see my changes, build the code and reproduce the issue., But with Accurev I am not sure how to do the same.
Reading the Accurev documents, it looks like a workspace acts as a stream but cannot be shared between developers.
It's been a few months since I've used Accurev, but if I recall correctly, your team members can browse your workspace. If you're browsing your available streams using the GUI tool, there should be a setting at the bottom to show workspaces from all users. This will allow them to at least browse your workspace. If you want other developers to be able to change these files, you'll have to push them up into a stream. If necessary, you can always create a new stream and re-parent your workspace.
If you have kept any files in your workspace, another user can look at the "Version Browser" of that element in their workspace and see your kept version and look at your changes.
Or, you could create a new stream, reparent your workspace to this stream and promote your changes into the stream.
In our Perforce workspaces at work, there are a couple of control files that contain branch information that should never be integrated across branches.
Is there a way to tell Perforce to always ignore these files in integrations?
You could set up a branch spec and use that for your integrations.
You may be able to use some type of permissions through p4 protect, so that only the admin can modify them. I know this works for actually checking out and checking in a file, but I'm not sure about integrating it to another branch.
You could write a server-side trigger script that looks for the control file names and filters them out of an integrate.
There's pretty good documentation on triggers. There's a load of examples too in the public Perforce depot.
I have a team that will be using CruiseControl for continuous integration, and CC will be running on a Linux server. More than one team member may need to access the CC configuration itself: changing how tests are run, changing notification rules, etc.
What is the best practice for this?
My first thought was to set up a cc-users group, then make a shared directory somewhere (such as /usr/local, I suppose, or a new directory like /projects), where the directory has r/w for the group.
Am I missing any complications with this plan? Obviously, I've never been in charge of such a project before, otherwise I wouldn't ask such a question.
FWIW, my intention is to have all the cc configuration files under mercurial so we can roll back in case of breakage.
I have version-controlled the whole of cruisecontrol configuration, along with the project specific config files underneath it.This way, the write-access can be controlled per requirement, using your source control tool's access control method (in our case subversion) thus providing tracking as well. Whomsoever needs to make a change can checkout the file config.xml in their own workspace and make their changes and then commit. You may want to consider the same approach.