I want to map a directory to different local folders (such as AA/adir and BB/adir) at the same time. Here's the spec below, but it doesn't work well.
Is there anything wrong?
//depot/adir/... //cws/build/AA/adir/...
//depot/adir/... //cws/build/BB/adir/...
In perforce, there is a strong requirement that there be a one-to-one relationship between the depot and a workspace. From the doc:
All views construct a one-to-one mapping between files in the depot and the files in the client workspace, branch, or label. If more than one mapping line refers to the same file(s), the earlier mappings are overridden. Mappings beginning with a hyphen (-) specifically exclude any files that match that mapping. In client views, mappings beginning with a plus sign (+) overlay previous mappings. (Overlay mappings do not apply to branch or label views.)
so a mapping like:
//depot/adir/... //cws/build/AA/adir/...
//depot/adir/... //cws/build/BB/adir/...
only activates the second line (which wins the conflict).
To do what you want, you need to use two different clients (workspaces) each having one line of your example.
You could look at overlay mappings, and maybe work around your problem:
An overlay mapping is used to map files from more than one depot directory into the same place in the workspace.
//depot/dir1/... //cws/build/...
+//depot/dir2/... //cws/build/...
In Perforce, you can have a many-to-one mapping but you cannot have a one-to-many mapping. You cannot sync same file to 2 locations. you need to provide it explicit list of what you want to sync. Something like this:
//depot/adir/... //cws/build/AA/adir/...
+//depot/adir/exception.c //cws/build/BB/adir/exception.c
Related
Can I have a workspace mapping where some depots or parts of depots get mapped as subdirectories of another depot mapping, like in this example workspace definition:
//Depot_Base/... //WorkspaceWithNestedMapping/...
//Depot_Sub1/... //WorkspaceWithNestedMapping/Sub1/...
//Depot_Sub2/D2/... //WorkspaceWithNestedMapping/D2/...
without p4 becoming confused where some added file below D2 should get stored on the server?
(Depot_Base vs Depot_Sub2, I want it to become part of Depot_Sub2)
Yes, this is completely possible and a very normal way of using workspace mappings. When different lines conflict, later lines override earlier ones.
One way to think about it is that for a given file path, the mapping is checked from the bottom up, and the first match is the one that is used. So if you do:
p4 add //WorkspaceWithNestedMapping/D2/foo
the matching line is the one at the bottom of the mapping, and the file is added as:
//Depot/Sub2/D2/foo
I am new to Perforce and want to create a automated tool to get the latest revision by itself. I have a mapping like this:
P4CLIENT: Proj_name
Worspace root direcctory: C:\...\Proj_name
Stream: Build
Now what i desire is it should get latest revision of all files from:
Build\fold1\fold2 to C:\...\Proj_name\fold1\fold2
When I just ran p4 sync command, it copied all files from Build to C:\...\Proj_name.
So please tell how to specify the folder path from where to get the latest revision. Will the command p4 sync //depot/proj1/... work for me and how does it change in my condition ?
You use the View: section of your client spec to describe which parts of the overall repository you wish to work with, and where those files should be placed on your workstation's filesystem.
In your particular case, to specify the folder path, as well as where those files should be placed, you might specify your View: as something like:
View:
//depot/Build/fold1/fold2/... //Proj_name/fold1/fold2/...
You may have considerably more complex view mappings; the view syntax is quite powerful. To learn more about view mappings, type p4 help views.
After you change your View: specification for your client, run:
p4 sync
The sync command will notice that you have changed your view mapping, and it will re-arrange the files in the root of your client on your workstation, so that they are arranged as described by your new view mapping.
If you don't wish to sync your entire client, you can specify a subset of the files which should be sync'd, by naming that subset of files using a file pattern as an argument to the sync command:
p4 sync //depot/Build/fold1/fold2/*.cpp
However, that can be quite confusing, and I recommend that, to start, you avoid using that advanced usage, and stick to performing a p4 sync with no file arguments, at least until you get more comfortable with how p4 sync is used. For one thing, when you are sync'ing different subsets of files with different file arguments, it is quite easy to get your workstation's filesystem into an un-buildable state, by getting half of the files from one changelist and half from another, which will cause you to have code that doesn't compile, etc.
So, for now:
Consider which parts of the repository you wish to work with, and where you want them to go on your workstation's filesystem
Run p4 client and describe the appropriate View: line(s) to specify those files, using the pattern-matching syntax of the View: field
Run p4 sync and Perforce will put those files on your computer as specified.
I'm using a single depot containing multiple projects stored in a directory-file structure. Each project can have multiple revisions, assigned outside of Perforce, e.g. A, B, C...
In Perforce (command line) I would like to assign these revision codes to corresponding perforce versions/changes, so that I can easily look up commits from each revision etc.
Multiple commits (changelists) can be attributed to each revision code.
My first thought was to somehow tag the files/changelists/? using labels called "A", "B", "C", etc., but as a given label can only be assigned to one version of a given file this would mean only one commit (the latest?) would be tagged for each revision. Plus, I'm not sure this would work for multiple projects.
So, is there a relatively simple way to achieve this within perforce?
Perforce File Attributes may allow you to achieve what you want, as they can be propagated to future revisions and allow you to set per revision attributes.
More information about them can be found here:
http://www.perforce.com/perforce/doc.current/manuals/cmdref/p4_attribute.html
You can't parse a changelist number to this command, but a bit of scripting could get you the revision numbers for files in particular changelist, which you could then tag with a particular attribute.
Hope this helps,
Jen.
Let's say I've shelved files A,B,C
I now want to unshelf this into a different branch, but my spec only has files A,B
Is there any way to do this so that perforce will unshelf the files that are mapped and ignore the rest? Right now I get an error which prevents me from doing any unshelving.
The use case here is I have one branch where I compile a third party lib, and I'd like to move over just the binaries and the public header changes. This changelist is huge so I'd rather not have to manually shelf only what is mapped.
To my knowledge I don't think you can use shelving to move changes from one branch to another. That would be a Merge/Copy depending on the situation.
Using shelving to do that would be a bypass of the (not saying malicious or intentional) versioning process.
We have two vobs which are "voba" and "vobb". And there is a directory "abc" in both vob and contains the same .h / .cpp files.
Usually, the files in "abc" dir in "voba" are updated quite frequently. And from time to time, I would like to update all files in "abc of vobb" from "abc of voba", which means:
Checkout the updated files in vobb.abc, overwrite them and then check in.
Copy the newly created files to vobb.abc, create element.
Delete the deleted files in vobb.abc by corrspoding to voba.abc.
If it is a common linux directory, I think cp -u and achieve that. But when it comes to the clearcase, I can only do the above 1-3 by hand.
Is there any easy way to finish that update automatically?
This is called in ClearCase a clearfsimport (potentially used with the -mirror option)
Since the elements in the directories abc of the two vobs are completely different (different oid, with different history), what you can do is import the content of abc from one vob into another: clearfsimport will automatically checkout, update and checkin only the files that have evolved in the source, and need to be updated in the destination.
Note, this recent thread (March 2013) also points out to the perl script ClearCase::SyncTree
It is superior to clearfsimport in many respects, especially in its evil twin avoidance (it will try with the proper options to link suitable entries from non visible versions).
Description:
This module provides an infrastructure for programs which want to synchronize a set of files, typically a subtree, with a similar destination subtree in VOB space. The enclosed synctree script is an example of such a program.
The source area may be in a VOB or may be a regular filesystem; the destination area must be in a VOB.
Methods are supplied for adding, subtracting, and modifying destination files so as to make that area look identical to the source.
Symbolic links are supported, even on Windows (of course in this case the source filesystem must support them, which is only likely in the event of an MVFS->MVFS transfer). Note that the text of the link is transported verbatim from source area to dest area; thus relative symlinks may no longer resolve in the destination.