How can I build a Build with single Changeset#? or Changeset numbers related to specific one file.
My scenario:
Changeset# 100 -> contains modified file X for problem Y
Changeset# 99 -> contains modified file Y but for different problem Z
Changeset# 98 -> contains modified file Z but for different problem W
I want to create a Build with just Changeset# 100. I don't want to include Changeset# 99 and 98 because that Changesets don't contain files related to file X. They contain different files Y and Z. That Changesets are not related to to Changeset# 100.
I want to include in my Build just files related to file X.
My steps:
Right click on the build: - Select "Queue Build" - Select "TF Version Control" tab - Type changeset number in "Get Version" for example changeset# 100
"Get version" is not working as I expected. It takes all Changeset numbers 100, 99. 98.
When you specify a Changeset to build, you're really just saying "build whatever the build definition dictates at that point in time", rather than the latest version.
So, in your case specifying Changeset #100 is going to include #99 & #98.
You could probably achieve this by creating another branch, performing a cherry pick merge into it (just #100) then clone and edit the build definition but I think it would get messy pretty quickly.
I suspect that you might be better off looking at a branching structure that would allow you to work on these changes in isolation (feature branching maybe) and then merging to your mainline branch when ready for release.
Related
I am trying to integrate a branch with several files that were moved. They were not modified in target branch, yet appear as conflicts. When clicking "accept source" file silently disappears from conflicts dialog, but still remains marked as conflict in the changelist. One way I can fix this is adding -Di flag, but it's a big no-no on my team. I also tried p4 resolve through command line, with same outcome (no error or anything, but nothing is resolved).
What is going on and how can I resolve preserving the move history?
Do:
p4 resolve -as
from the command line. In the vast majority of cases that's all you need to do; it tells resolve to accept the change relative to the base (which means accepting the source in the case where the target hasn't changed).
(updating to include additional info from comment)
If after you do that you get an error like:
can't move (open for delete); must accept other resolve(s) or ignore
it means that the file was moved in the source (which means that normally a resolve -as would move the workspace file to match it), but the file in your workspace can't be moved because it's already open for delete (you can't move a deleted file). This is a pretty rare situation that happens if you move a file, delete it, and then try to resolve those two operations independently (but without submitting in between). In that case you probably want to specifically "ignore" the move resolve (like the error message suggests) by doing:
p4 resolve -ay
If you've somehow gotten your working file into a bad state (maybe you were running random commands before setting up the integrate and the workspace wasn't in a clean state) and either can't figure out how you got here or have no interest in doing forensics when you just want to do a basic integrate and forget about whatever you were in the process of doing before, you can always start over like this:
p4 revert FILE
p4 integrate -b BRANCH FILE
p4 resolve -as
If you have a file that was moved and then deleted in the source, it's not possible for both of those actions to be represented in a single changelist in the target, so the default is to ignore the move and accept the delete (on the theory that since the file is deleted anyway, it doesn't particularly matter where it's deleted):
C:\Perforce\test\movedel>p4 integ A/... B/...
//stream/main/movedel/B/foo#1 - integrate from //stream/main/movedel/A/bar#1,#2 (remapped from //stream/main/movedel/B/bar)
C:\Perforce\test\movedel>p4 resolve -as
c:\Perforce\test\movedel\B\foo - resolving move to //stream/main/movedel/B/bar
//Samwise-dvcs-1509687817/movedel/B/foo - ignored //stream/main/movedel/B/bar
c:\Perforce\test\movedel\B\foo - resolving delete from //stream/main/movedel/A/bar#1,#2
//Samwise-dvcs-1509687817/movedel/B/foo - delete from //stream/main/movedel/A/bar
Note that after resolving move we see an ignored and after resolving delete we see delete. Note also that the history of B/foo is linked to A/bar, which contains the history of the move, so the history isn't "lost", it's just not duplicated.
If you do want to duplicate the move history from the source into the target (so that the target, viewed independently of the source, shows the file as having been moved and then deleted), you need to do the integration in multiple submits:
C:\Perforce\test\movedel>p4 revert ...
//stream/main/movedel/B/foo#1 - was delete, reverted
C:\Perforce\test\movedel>p4 changes A/...
Change 316 on 2022/12/08 by Samwise#Samwise-dvcs-1509687817 'delete bar'
Change 315 on 2022/12/08 by Samwise#Samwise-dvcs-1509687817 'move foo to bar'
Change 313 on 2022/12/08 by Samwise#Samwise-dvcs-1509687817 'add foo'
C:\Perforce\test\movedel>p4 integ A/...#315 B/...
//stream/main/movedel/B/foo#1 - integrate from //stream/main/movedel/A/bar#1 (remapped from //stream/main/movedel/B/bar)
C:\Perforce\test\movedel>p4 resolve -as
c:\Perforce\test\movedel\B\foo - merging //stream/main/movedel/A/bar#1
Diff chunks: 0 yours + 0 theirs + 0 both + 0 conflicting
//Samwise-dvcs-1509687817/movedel/B/foo - copy from //stream/main/movedel/A/bar
c:\Perforce\test\movedel\B\foo - resolving move to //stream/main/movedel/B/bar
//stream/main/movedel/B/bar - moved from //stream/main/movedel/B/foo
C:\Perforce\test\movedel>p4 submit -d "integrate #315"
Submitting change 317.
Locking 2 files ...
move/add //stream/main/movedel/B/bar#1
move/delete //stream/main/movedel/B/foo#2
Change 317 submitted.
C:\Perforce\test\movedel>p4 integ A/... B/...
//stream/main/movedel/B/bar#1 - delete from //stream/main/movedel/A/bar#2
C:\Perforce\test\movedel>p4 submit -d "integrate #head"
Submitting change 318.
Locking 1 files ...
delete //stream/main/movedel/B/bar#2
Change 318 submitted.
What is going on
Perforce is not able to deal with moved files in merge/integrate properly. I can confirm that this is still an issue in the most recent version. We have this case regularly.
Say, team A is working on //OurDepot/ExclusiveContentOfTeamA/ and you are then merging that to team B's branch. Consider the case where team B has not touched (or even looked at) that location.
Merging should be a breeze in this scenario, right? Wrong!
If team A moved and deleted files, it is always a dice roll whether the merge will work or not. Most of the time "accept source" will resolve the issues, but sometimes you get the state you described in your question.
and how can I resolve preserving the move history?
You can't. All you can do is some hacky solution forcing perforce to delete the files (p4 resolve -ay), and then manually repair the state in the branch by re-adding the files as new files. History will be lost.
I have two project namely say X and Y
Where x contains all code and configuration
And Y contains testData and Feature files which is manage by some other team.
I had created a job in jenkins to run my X project initially which is working without any issue. Now I want at run time I poll the Y project and check if they had any new commits then first I merge it else leave it.
Currently I am able to check the last commit but still not able to merge project
My both X and Y are Karate API project
I think you need to design differently. Maybe the right solution is X should create a JAR file. And then in Y you depend on that JAR file. Now it has become a standard CI / Jenkins situation.
My advice is don't try to re-invent polling and merging and whatnot - those are all solved problems.
I achieve this using git submodule concept and it not required anything to done on CI.
git submodule add <repository URL
Is there a way to update the member revision of a big list of files via command line?
I can't use :working or :head but have to specify a different revision for each file.
As far as I know --selectionFile only takes paths as input, but not the revision numbers.
edit: I wanted to set member a very big list of files and I wanted to avoid writing the command si updaterevision ... for every file, as it takes ages to complete for that many files. Instead I wanted to know if there is a more advanced method to specify a list of files and their revisions to be able to run the updaterevision only once (like it is with :working) for the whole list of files.
But as it is said in the comment there is no such possibility.
edit2: I use MKS for a couple of years now and as I now know, there is no such possibility (at least up to MKS 11.6) to update many files to different revisions with one single command line call. But using one call per member, as was proposed, made the whole operation take up to several hours as I had many thousands of members in the sandbox and MKS needs some time to complete each sicommand.
Some time already passed since you asked for this question, here is my comment in case it could still be useful for you in the future.
First, It is not completely clear what you want to achieve. Please be more descriptive and if possible provide example.
What I understand as of now is you need to set bunch of files listed as member revision thru the command line. This is fairly simple, the most complicated is actually to have the list of files to be updated to member and the revision that you want to set as member.
I recommend you to create a batch file with the commands to make each file member. You can use Regex to do it very quick and without much trouble.
Here is an example for updating one file member revision:
si updaterevision --hostname=servername --port=portnumber --user=username --changepackageid=5873763:2 --revision=:working myfile_a1.c
where
servername = the name of the server where your sandbox is located
portnumber = the port that provides access to the server for your sandbox
username = your login user id
changepackageid = here you change the number to use your defined TASK:ChangePackage for this changes
revision = if you have a working revision that you want now to become member, just use "working" as revision, otherwise you can define specific revision number, e.g. revision=1.2
At the end you define the name of the file you want to update.
Go to you sandbox root folder, open CMD window, and run the batch file. It will execute each line applying your changes.
If you have a list of files with the revision you want as member, you can use REGEX to convert it into a batch file.
Example list of files in text file:
file1.c 1.10
file3.c 1.19
sec_file1.c 1.1.2.1
support.h 1.7
Use notepad++ or other text editor with regex support and run this search:
Once you know which regex apply, you can now use it in the notepad++ to do a simple search and replace:
Search = ([\w].[\D])\s+([\d.]+).*
Replace = si updaterevision --hostname=servername --port=portnum --user=userid --changepackageid=6123933:4 --revision=\2 \1
\1 => FileName
\2 => File revision
See image below as example:
Finally just save doc as batch file and run it.
Just speculating that if you have a large list of members along with the member revision you want to update to, then you also have an sandbox that served you to generate this list.
If so my approach would be
c:\MySandbox> si updaterevision --recurse --revision=:working
If your member/revision list come from a development path you could first have a sandbox targeting that devpath, resync, (close thesandbox if opened in gui), retarget the sandbox to the destination devpath (or mainline) you want and then issue the command above.
For an single member approach I would use 'si rlog' to generate a list of si-commands directly
si rlog -R --noheaderformat --notrailerformat --revision=:working --format="si updaterevision {membername} --revision={revision}\r\n" > updaterevs.bat.txt
Review updaterevs.bat.txt rename it to updaterevs.bat and ecxecute it.
(Be careful if using it on other sandboxes)
Other interesting readings here might be the "snapshot sandbox" feature,
checkpointing in general and variants rsp. devpaths.
Using only these features might be politically more correct in the philosophy of Integrity.
I need to write a script in Gradle that takes as an input 2 folders.
Both folders contain <1000 files (mostly images) with reasonably similar structure.
The output should be a list of files that changed and what kind of difference it is (added file/deleted file/changed file).
Edit: Heres a sample script https://gist.github.com/igormukhin/71d780c4274336eeb297 . The only problem is that it compares by timestamp.
I have recently coded up something similar to what you are asking for: DirectoryDifferenceCollector; however, it actually compares the contents of the files (as a hash) and not the timestamp. I would be willing to update it to accept a configurable strategy if that would suit your needs, or you can just use the concepts involved.
Basically it scans both directories and determines the missing files in both A and B and then it also determines which files are common to both directories, but have different content.
The results are collected in a DirectoryDifference object with the respective file paths for each category.
I'd be tempted to use diff:
def process = 'diff x y'.execute()
You can then access the output of the command as text:
println process.err.text
println process.in.text
And get the exit status via:
int status = process.waitFor()
Many common operating systems will come with diff installed, but Windows probably does not.
I discovered that some old branch integrations in Perforce re-created some files that were previously deleted. Because this was not caught in time, later integrations also modified the branched file.
For example:
MAIN BRANCH
cl 1: X rev#1 == X rev#1
cl 2: X removed in branch
cl 3: X rev#2
cl 4: main -> branch integration, X#2 reappears
cl 5: X rev#3
cl 6: main -> branch integration, X rev#3
What is the "Perforce" way to back out these changes. Clearly, I could go in and delete file X in BRANCH and submit that. However, if it were 100s of files, this would be quite a task.
The more correct path, would seem to be to back out the integration of the file. However, I attempted this, and Perforce does not actually mark the file to be deleted.
Its not clear if you should backout change list 6, or change list 4?
Is this a perforce or user bug? Maybe there is some flag to force perforce to remove files during a "back out" operation.
I'd back out changelist #4. There's no fully automated way to fix this. You could probably write a script that takes care of most of the grunt work. In the future you should use a branch spec to tell Perforce to ignore file 'X' in all future merges.