I am trying to integrate a change list from one branch of code to another branch.For this I do
1)p4 integ old_branch#cl,cl new_branch
2)p4 resolve -am
3)p4 change.
Now when I am doing the last part(p4 change ) I see this error :-
The document “tmp.BLAH BLAH” could not be opened. You don’t have
permission.
Has anyone seen this before and can help me correct this?I do have the config file under the branch's root
I was using P4V with Perforce when I had to use it. Drastically helped me with merges considering P4 is not quite like using SVN or Git.
Also I think that if the file can be removed from your filesystem you can revert to the latest from the repository if in fact it is a file from the repository. Then you can retry your merge.
I know in other merge programs the tmp files are generated during the conflict resolution process so you may be facing a similar issue.
Related
Is there a way to modify folder structure (path) for pushed commits in Gitlab?
For example, my old path is homework, now I want to add a parent folder before that, i.e. superfolder/homework? Tks and welcome for any help
If you want to do so while keeping the history of homework, you need to install the Python-based tool newren/git-filter-repo.
That tool has a renaming based on paths option
In your case:
git filter-repo --path-rename homework:superfolder/homework
Note that it changes the history of the repository, which will have to be forced pushed (git push --force): not a big deal if you are the only one working on it.
The Scenario
I want to rollback a changeset.
The Problem
When I perform Rollback Entire Changeset from my $/SAM/Main branch using the VS2012 IDE, the Resolve Conflicts tab displays, and ALL of the files I'm trying to rollback have the following message associated with them:
The item being rolled back has changed in a later version
Changes being rolled back: 54460~54460 Your workspace version is: 54460
You have a pending change on the item
At this point, the only option available to me in the Resolve Conflicts tab is an Undo Rollback button.
Things to Note
CS54460 was created using the following command line:
merge $/SAM/Dev $/SAM/Main /discard /recursive /version:C54426~C54426
CS54460, when viewing the Changeset Details, performs a [merge, branch, delete] on ALL the files.
Why I Need to Do This
I need to do this, because I need to merge CS54426 from the $/SAM/Dev branch up to the $/SAM/Main branch.
Don't use rollback, just do it manually:
get the version you want to roll back to
back up the changed files
check out the changed files. If you're lucky the old code will be preserved but the checkout may force you back to the newest version.
so if necessary copy the backups over the master source files again
test and check in
My problem was solved by using the following command:
merge $/SAM/Dev $/SAM/Main /recursive **/force** /version:C54426~C54426
This forced the changeset I needed in $/SAM/Dev to disregard the "Keep Yours" changeset in $/SAM/Main, thus merging the code I needed up to the $/SAM/Main branch.
I was getting the error "TF203051: Cannot rollback item XYZ because the workspace version of the item is at or older than the version to which you are trying to rollback to. Update the version in your workspace to a newer version than the version to which you are trying to rollback to and then retry your operation." when attempting to roll back to a specific version in the history in VS2017.
The problem was that file XYZ, one of the files was included in multiple changesets, a second one was more recent than the one I was trying to roll back.
Luckily I needed to roll back that too. So the solution was to roll back both versions at the same time by selecting them together in the history view of Source Control Explorer.
I have created feature branch for one of our projects, and deleted all documentation files there in one changelist. (I know, bad idea).
I want to integrate back everything except given changelist, I tried following to ignore it:
p4 integrate //branch/...#CL,CL //main/...
p4 resolve -at //main/...
However, the files still remain marked for deletion - the resolve ends with
//main/... - no file(s) to resolver.
Is there any way how to tell perforce that given CL is already integrated and ignore it in subsequent integrations?
Note that you need at least a 2011.1 server to do this (if your server is older you'll get an error message on the integrate):
p4 integrate -Rd //branch/...#CL,CL //main/...
p4 resolve -ay
The "-Rd" flag says that files which would normally be opened for delete automatically should be opened for integrate and scheduled for resolve instead. In turn, the "p4 resolve -ay" will say that you want to keep what's in your workspace (an "integrate" with no content change) and submit that as the final result.
The submitted "integrate" revisions will record that you have done this integration (the history will show an "ignore" of the deleted revisions in your branch), but without actually changing the contents of the submitted files.
If you use the "p4 merge" command instead of the "p4 integrate" command (with a more current server version, I think 2013.1 or thereabouts), all files are scheduled for resolve automatically (i.e. including those that would previously have been automatically opened for branch or delete), so with "p4 merge" you always must resolve (and may optionally ignore) any source change.
Relevant p4 blog entries:
http://www.perforce.com/blog/110620/ignoring-branches-deletes
http://www.perforce.com/blog/130812/resolve-face-adversity
It seems like you wanted 'resolve -ay' here, not 'resolve -at'. When integrating back to main, I think that "theirs" is the branch, while "yours" is main.
From 'p4 help resolve':
The resolve process is a classic three-way merge. The participating
files are referred to as follows:
'yours' The target file open in the client workspace
'theirs' The source file in the depot
'base' The common ancestor; the highest revision of the
source file already accounted for in the target.
'merged' The merged result.
Filenames, filetypes, and text file content can be resolved by
accepting 'yours', 'theirs', or 'merged'. Branching, deletion, and
binary file content can be resolved by accepting either 'yours' or
'theirs'.
I have two branches _trunk and _dev.
There is a folder (actually it's config) where intensive work is performed in both branches.
Now I need to merge from _trunk to _dev. But I need to merge only the code.
The config should be REPLACED. I'm not sure that replacing it manually is right way. How this operation is called? How do you do similair things?
It's an integration as usual, but during resolve you'll accept the source files without trying to merge them into the destination. This will replace the destination files' content with the source content.
Edit: If there are adds and deletes in the source, make sure you let Perforce propagate those with the appropriate options checked.
You can do an "Integrate/Merge" from _trunk to _dev. Any conflicts will set up in your pending changelist as a "Resolve" for each file.
For code you can let P4V attempt to merge it for you and make changes / do the merge manually. For the config files, in the resolve window do "Accept Source" - this overrides the target with the source regardless.
Likewise, if there's any where you know you don't want to bring your changes forward but still want it to recognise you've checked and accomodated for the changes, use "Accept Target"
Maybe some Perforce gurus could provide some advice.
We have a depot, with a setting.xml file in central folder:
///depot/central/config/setting.xml
and would like it to be instanced in several locations, like:
///depot/projectA/tool1/config/setting.xml
///depot/customerB/tool2/config/setting.xml
The benefit is for maintenance. the setting.xml file only has to be updated once in //depot/central, then all files in the other places get updated as well, so we don't have to get into each place, duplicate it again and again.
AlienBrain has a feature called 'shortcuts', does Perforce have something similar?
We've tried use the OS' symbolic links feature, but it didn't behave the way expected -- cloned files still need to be checked-out first, then check them in again -- this makes the cloned files own their own revisions against the original one.
It's better to just keep the original and cloned files have the same revisions. so if submitting a new revision to setting.xml(5/5)(which makes it to be setting.xml(6/6)), the cloned files as this point still remains setting.xml(5/6). Thus, people on projectA & customerB can simply sync to the latest version.
Thanks.
You can use the Perforce client spec to map files from the depot into your workspaces, which should do almost exactly what you're looking for.
For example, your client spec for tool 1 would be something like:
//depot/projectA/tool1/... //workspace_for_tool1/...
//depot/central/config/setting.xml //workspace_for_tool1/config/setting.xml
And your client spec for tool 2 would be something like:
//depot/customerB/tool2/... //workspace_for_tool2/...
//depot/central/config/setting.xml //workspace_for_tool2/config/setting.xml
The main downside of this approach is that you need to make this change in every client spec, and you need some infrastructure dedicated to propagating client specs to new workspaces.