I've imported a project into a directory and the original directory structure is:
//depot/a/b/foo.txt
//depot/a/b/bar.txt
//depot/a/b/c/baz.txt
//depot/a/b/c/boz.txt
Note that none of the files in //depot/a/b have name conflicts with files in //depot/a/b/c.
I'd now like to reorganize things such that all of those text files reside under //depot/newdir/. I attempted this by creating the following branch spec with view lines similar to the following:
//depot/a/b/... //depot/newdir/...
//depot/a/b/c/... //depot/newdir/...
This didn't work. When I integrate, the files in //depot/a/b/c clobber those in //depot/a/b. If I reverse the lines the files in //depot/a/b clobber those in //depot/a/b/c.
I've tried various wildcards (such as the following) hoping to be more specific, and can't get this to work.
//depot/a/b/%%1.txt //depot/newdir/%%1.txt
//depot/a/b/c/%%1.txt //depot/newdir/%%1.txt
Is it possible to migrate all of the files as described above to the //depot/newdir area in a single branch spec?
You should be able to use the move command here.
p4 move //depot/a/b/* //depot/newdir/*
p4 move //depot/a/b/c/* //depot/newdir/*
Those two commands will move all the files in b and c (but not any files in their subdirectories) to newdir.
Related
Is it possible to use multiple p4alias files, like one personal p4alias file and one project related? I do not see a way to source or concatenate multiple files.
Practical answer: not really, no -- you should just copy and paste the project alias file into your personal alias file. A fun trick here is to keep the aliases file in the depot, so you can use merging to pull project-level changes into your personal file without having your own changes go back.
Impractical answer: run something in the background that will concatenate the files together for you and surface them as a single p4aliases file, e.g. https://superuser.com/questions/762590/can-i-create-a-symlink-esque-file-to-merge-two-files-together
If I issue
p4 sync ...
it only syncs the files in my CWD and below to HEAD.
However, I am trying to sync a single directory to a label name
p4 sync #LABEL_NAME ...
and the result seems to be that the entire workspace (all files tagged with that label) is then sync'ed to that label, as though I had not added the "...".
Is this expected? And if so, how do I achieve what I want?
The #LABEL_NAME is a "revision specification", while the ... is a file pattern; what you want to do is to combine them, and specify both (the files in this directory and any sub-directories, at the revision in which they were tagged in the label).
To do that, you stick the revision specification after the file pattern, with no spaces between them:
p4 sync ...#LABEL_NAME
For more information about the things you can stick after the file pattern to refine your set of files, run:
p4 help revisions
I have a file of name: test.c in perforce, but i want it as Test.c (capital T).
I tried rename, delete and then add but both methods are not useful! The file gets update in my machine, but when some one else accesses it, the file remains, test.c itself, not Test.c!
What can i do in this case?
And i have many files of same name inside the directory in perforce, i want to rename them all.
Ex:
dir1->test.c , dir2
dir2 ->test.c , dir3
dir3->test.c
This should become:
dir1->Test.c , dir2
dir2 ->Test.c , dir3
dir3->Test.c
If the file name appears correct when looking at the tree in P4V, but is the wrong case on the client machine, try removing the file from the workspace and then resyncing. Windows won't rename the file if it's already on disk because it's a case insensitive file system.
This is a longstanding bug with Perforce/Helix that they have consistently refused to fix for over 14 years.
The Helix knowledgebase workaround does NOT work, don't waste your time.
The closest I've found to a solution is the following:
Rename the file to an interim string that you will never use in the future and have never used before - eg add a UUID postfix
Commit this change
Copy up to the highest applicable parent stream
Merge down into ALL streams that will ever need the change and have the original erroneous name. You can filter the merge down to just the rename/move operation.
Get Latest on ALL Windows workspaces for the affected streams
Rename the file to the final case-sensitive string
Commit this change
Copy up as per step 3
Merge down as per step 4
Important: You MUST copy up and merge down while the file has the temporary name.
Perforce does not take interim changes into account when merging down or copying up - this is different to every other source control system that I'm aware of and caused much heartache.
Note: While file history across the rename is apparently preserved in the database, it appears that you can only see that the rename occurred and cannot diff or merge across the change.
I'm trying to use p4 sync to sync a specific directory to a given changelist number using wildcards but I also want to exclude a list of files that are under that directory (in subdirectories), I tried using - (both before and after using a path with wildcards) but the file never gets excluded, this the command I'm trying:
p4 sync //Repo/Foo/... -//Repo/Foo/Bar/Foobar.txt
The file exclusion seems to only work when the files/directories you are syncing don't match the files you're trying to exclude.
In your client, you would have multiple lines:
//Repo/Foo/... //my_client/Repo/Foo/...
-//Repo/Foo/subdirectory/... //my_client/Repo/Foo/subdirectory/...
This would allow you to get everything in the Foo directory and all subdirectories except "subdirectory".
You can do this if you use a label. Create a label in your favorite editor (p4v or command line p4 label and add your two lines:
//Repo/Foo/...
-//Repo/Foo/Bar/Foobar.txt
In the revision field put "#head" (including quotes!) if you want the latest or a change list number. Give the label a name - for instance "sync_butnot_foobar"
On the command line you can now sync:
p4 sync #sync_butnot_foobar,#sync_butnot_foobar
This has a huge benefit over the modify your client spec and sync head model. If you exclude a file in your client spec, the next time you sync that file will be brought to revision 0 which probably isn't what you wanted.
In short, you can't exclude files on a sync. That can only be done within the client spec. (Well, it could be done through the protections table, but that is really a different matter I think).
But if you want to sync a specific folder and only the files in that folder, use *
p4 sync //Repo/Foo/*
will get you only the files in the Foo folder.
I am working on a shared project which is put in SVN. The directory structure of the project is as follows:
ParentDir
- Child_Dir_1
+ GrandChild_Dir_1
+ GrandChild_Dir_2
- Child_Dir_2
Child_Dir_1 contains configuration files (Eclipse's .LAUNCH files), and people put all sorts of file in this folder.
So each time I update my source code (by right clicking on ParentDir and picking Update), I got a lot of configurations that I don't really need, and I have to delete them manually.
I still need to have the children of Child_Dir_1 (which are GrandChild_Dir_1 and GrandChild_Dir_2) to be updated.
I have tried to go to set the "ignore" property of the of Child_Dir_1 to exclude *.LAUNCH files, but each time I update the source code, the ones that I manually deleted are restored to Child_Dir_1.
Since you are using TortoiseSVN:
Go into Child_Dir_1, select GrandChild_Dir_1 and GrandChild_Dir_2 and right click, TortoiseSVN -> Update.
That will update only those two folders.
Ignore is so that you can "ignore" ( from commit, status etc.) untracked files, files that are not checked in.
It could be that manojlds' answer is the solution for you, but I have doubts. The problem here is that those files are really part of the project. They are kind of unavoidable, and must be in sync with the rest of working copy.
Option 1 (best): Remove all configuration files form repository, or better yet have in repository only configuration template files (with, say, $ as first character in file names). Each user could copy those template files to true configuration files and change them accordingly. Configuration files should not ever be committed. Only template files should, but updating template files will not mess with current configuration files of any user.
Option 2 (second best): Ignore those configuration files. Use your own files for your own configuration, with names that don't clash with existing. You may even add your files to SVN, but you may just as well not add them. Does not matter, as long as you don't need your configuration on another machine.
Option 3: Use ignore-on-commit group. Use those configuration files that already exist. Change them to your likings, but don't ever commit them. To ensure that you don't commit them by accident flag them as non-committable (go to commit window, select all non-committable files, right click > Move to changelist > ignore-on-commit). The problem with this is your files are not protected from other users' updates, but may actually be a good thing.
Option 4: Chop the folder out (a horrible hack). Remove Child_Dir_1 from working copy (Right click on it > Update to revision > set Working depth to Exclude). Save the folder elsewhere first, because it will disappear. After that create it again, inside it checkout all subfolders (GrandChild_Dir_1 and GrandChild_Dir_2), and copy your configuration files. Now you have complete control over folder's contents, but update and commit become more complicated.
Edit: There is option 5 in theory, but I doubt it can be implemented successfully. You can try: Use NTFS hard links. Copy the whole tree with all files as hard links to existing files, except .svn folders and their contents. Original directory is used for SVN operations update, commit, add and delete, and new directory is used for editing files. From new directory delete all the files you don't need, and insert all the files you do need that are not the part of SVN. The problem here is minor extra work when deleting files from and adding them to SVN.