As a new perforce user I had to made a decision, that was very probably wrong.
My customer has the following depot structure:
//depot/dir_a
//depot/dir_b etc.
dir_a and dir_b describe no branches, they are pure directories. The whole project simply populates //depot.
I had to create a branch from this and tried to set up something like a SVN or git standard tree:
//depot/master/dir_a
//depot/master/dir_b
//depot/branches/1.0/dir_a
//depot/branches/1.0/dir_b
At the specific moment I wasn't allowed to change the old structure, but only to add things. So, I have been ending up with
//depot/dir_a
//depot/dir_b
//depot/branches/1.0/dir_a
//depot/branches/1.0/dir_b
Now, I am recognizing some pitfalls here: For example, it seems non-trivial to merge between //depot and //depot/branches/1.0 (the later being a sub-directory and probably some kind of 'part' of the informal pre-existing 'root' branch).
How can I fix this (provided that I'm now allowed to create a 'master' and moving the old stuff into it)?
If you haven't started creating "master" and "branches" etc yet, I'd just do:
p4 integ //depot/... //depot/master/...
p4 delete //depot/...
p4 submit
Now everything is in "master" and you can move forward (just ignore all the deleted files outside of your new directory structure).
If you've already put things into "master" and "branches" then you'll have to work around them, which isn't that hard but requires a little bit of thought so you don't end up creating "master/master" etc. Something like:
p4 delete //depot/...
p4 revert //depot/master/... //depot/branches/...
p4 integ //depot/... //depot/master/...
p4 revert //depot/master/master/... //depot/master/branches/...
p4 submit
In any case, you want to move your work into the "master" directory because as you've noted it's going to be easier to merge between "master" and "branches/whatever" than it is to merge from the root to something underneath of it.
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.
I am new to perforce. I have a requirement to create a trigger to avoid integrating changes from one particular branch say 'branch_testing' to 'main' branch.
How can we do this? Could you please help?
If you want to absolutely prevent changes from going from branch_testing to main, you need to use the protections table and do one of two things:
Remove "read" access to branch_testing.
Remove "write" access to main.
Otherwise, even if you implement clever controls on the integrate command, there's nothing to stop a user from doing:
p4 sync branch_testing/...
p4 edit main/...
cp -r branch_testing main
p4 submit
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'.
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.
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.