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
Related
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 have some files, like upgrade01.x and upgrade02.x, where the name defines some order. Due to external constraints, I must use this naming convention but I want so swap them, 01 become 02 and 02 become 01. I tried renaming update01.x to a temp name (without submitting it), then tried change update02.x to be update01.x but perforce doesn't let me do that.
I can submit the rename to something temporary, then rename one to the other, then the rename the temp, but is a monster pain. Also, the history looks really weird (but that might be unavoidable).
Is there a way to do this in one sane operation?
Doing the rename in two steps (rename both to intermediate names, then each back into the place of the other) might be the preferred option if you want the "identity" of each file to follow it to the new name (e.g. when you merge from other branches, you want merges to be remapped according to the new name rather than going to the old one).
If your priority is to have this happen in a single changelist, though, and you're not so concerned about whether the history preserves the notion of which file is which, I'd do it like this:
p4 copy upgrade01.x upgrade02.x
p4 copy upgrade02.x upgrade01.x
p4 submit
This will get you a nice neat little X in the revision graph (which I suspect is what you want), but not a true rename.
Merging to/from other branches will be a little tricky either way; if you go the true rename option, when you merge the rename to other branches you'll need to go change by change to repeat the process of renaming to something intermediate and then back (since the target branch will have the same constraint of not being able to rename onto something that is itself already open for rename). If you go the copy option, you'll need to manually specify which file to merge into which depending on what state each branch is in and whether there are outstanding changes requiring an actual merge.
I'm wondering what actions results in the left part of the graph, i.e. the red dashed arrow? This was done by Unreal Engine's Perforce plugin, when I renamed this file and submitted this change. The action shows add if I highlight that revision, but according to legend, this is a merge w/ edit action, so it doesn't seem to match.
The right part is my test, using P4V's move/rename action, and the action shows move/rename, which matches the legend Add (branch w/ edit), so this one seems fine.
So, what exactly happened in the left part? Is it really a merge w/ edit? Is it a correct result if someone is doing rename? Is move/add the only correct result when doing rename?
Thanks.
It's a mind-twister but there isn't necessarily a mismatch.
First the actions: the first is an add because the new file is created in addition to the old one. In contrast, the second is a move/add because you're adding a file by moving it from the old location, hence the old one ceases to exist. Indeed, you start the whole exercise with one file, and end it with two (rather than with three, as you would if you performed two adds; or rather than with one, as you would if you perform two move/adds).
Now the arrows. You're right the naming seems completely out of touch with the naming of the actions. I have no idea why there's the inconsistency.
You're asking about the Merge w/ Edit specifically. Perforce has four similar but distinct actions that could have been used here: p4 integrate, p4 merge, p4 copy, and p4 populate. There are subtle differences that don't matter here. At any case, all these actions do "merge" the file so I think the naming is OK. Intuitively, I feel this could/should have been done by p4 copy (since the target didn't exist, so you didn't have to merge anything) but it's also perfectly possible that Unreal Engine decided to use p4 merge or p4 integrate anyway. That, I believe, explains why the arrow is a Merge. As for the w/ Edit, did you perhaps make a (textual) edit in the file while duplicating it?
I am using Tortoise SVN 1.6.16 in Windows 7. If I have a certain file type I want to exclude from future commits, I thought I could just go find a file of that type within my working folder, then right click it, and select "TortoiseSVN->Delete and Add to Ignore List->*.ext" where ext is the file extension of the file I clicked, as shown in the image below.
However, when I do this, it only excludes that specific file, and the next time I commit, all other files of that type still come up in the list to commit.
Am I doing something wrong? How can I just tell Tortoise or SVN to ignore all files of a certain type from future commits?
I had the same hunch as #Stefan: that you were probably seeing files in subdirectories and thinking those should have also been ignored even though you only applied the ignore to a single folder.
So if that is in fact the case, here is the recipe:
When you want to ignore files or patterns from a single directory:
Use the convenience menu command to add to the ignore list.
When you want to ignore files or patterns from a subtree:
Open the subversion properties (TortoiseSVN >> Properties) of the root of the subtree. Add or edit an entry for the svn:ignore keyword. The illustration shows an example where I have specified to ignore an obj subfolder as well as all files with a .user or .bak extension.
The secret, though, is in the specification--when you define the patterns to ignore, select the recursive choice as indicated here:
Unfortunately, there is one catch to this method: In my example, I had previously specified to ignore obj and *.user and I was adding just the *.bak pattern. When I apply recursively, it does not apply just the change (*.bak) but everything in the svn:ignore keyword (obj, *.user, and *.bak) to all subfolders. That may or may not be what you want, so be aware of it.
It ignores all bat files right, but not recursively! It only ignores them in the folder you added it to the ignore list.
You could also use Tortoise's global ignore pattern (if it's applicable to all your working copies):
TortoiseSVN -> Settings
General
Fill out the "Global ignore pattern" field, such as adding "*.ext" at the end of it, separating entries with a space.
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