Uploading delta changes to perforce and label - perforce

Every month I need to sync big chunk of files from git and upload it to perforce and create a p4 label with all files uploaded, and from p4 I do builds, this is odd but we cannot change this now. so far I am uploading the files to new directory in p4 every time and creating label with all uploaded files, so I get a clean label for "this month's build" though most of the files didn't change compared to last month's upload, this happens through shell script, is there a way to upload only the delta changes and create label with old files (not uploaded as it didn't change) + changed/brand new files uploaded? any high level directions will help, thanks.

Do I understand correctly that "I am uploading the files to new directory in p4 every time" means that, each time you perform a 'p4 submit', the files in your changelist are actually different file names, not just newer revisions of the same files?
That is, if you did 'p4 describe' of the first changelist you submitted, would it look like:
//depot/dir/r1/A.c#1
//depot/dir/r1/B.c#1
//depot/dir/r1/C.c#1
while the next time you ran your tool, and did a 'p4 describe' of the changelist, it would look like:
//depot/dir/r2/A.c#1
//depot/dir/r2/B.c#1
//depot/dir/r2/C.c#1
If that is what you are doing, then if you could instead copy the files to the same location each time, so that the first time your tool ran you got:
//depot/dir/A.c#1
//depot/dir/B.c#1
//depot/dir/C.c#1
and the second time your tool ran you got:
//depot/dir/A.c#2
//depot/dir/B.c#2
//depot/dir/C.c#2
If you did things that way, then you could use the 'revertunchanged' feature of Perforce, and the files that were unchanged from the previous run of your tool would not be submitted, and the revision number would not change, so that over time you might get:
//depot/dir/A.c#7
//depot/dir/B.c#4
//depot/dir/C.c#19
Each time you run your tool, you can still create a label, because the label includes not just the file name but also the revision number, so the first label you created might include:
//depot/dir/A.c#1
//depot/dir/B.c#1
//depot/dir/C.c#1
while the 19th label you created might include:
//depot/dir/A.c#7
//depot/dir/B.c#4
//depot/dir/C.c#19
Hopefully this will get you pointed in a direction that is more suited to your goals.

Related

Perforce: The submitted file doesn't match workspace version

I am facing a weird behavior in perforce submitted files, after p4 integrate
Scenario
Repo contains C# code and the built DLL. I wished to integrate a changeset from one branch to another
so I am following the steps which I had discussed, a while ago
The .cs files doesn't complain. If there is resolve conflict in the DLL, I choose either of Accept Source or Accept Target without much care. Reason being, I always rebuild the DLL before submitting
Issue
The DLL which was built in local workspace and reflected in the changeset is correct. I tested it locally and do p4 submit. But to my amazement, the DLL submitted is not the one which I had built. Instead the one which came from that other branch was submitted
Confusion
I thought that with perforce, when a file is opened in a changeset, always the latest(local) copy will be submitted. That is why I don't pay much attention if there are conflict reported in DLL
Isn't that correct ?
Why would the submitted file be different from my workspace version ?
When you "accept source" you're recording that you want the target file to be an exact copy of the source file; consequently, if you submit the file, it's not even transferred from the workspace (in order to save time) -- instead it's just copied server-side. If you tampered with the workspace file, this leads to the situation you describe where the workspace is now inconsistent with the depot, just like if you'd modified a file that wasn't open for edit.
If you submit with the -t flag (for "tamper checking"), it will check for tampered files by comparing what's in your workspace with what should be in your workspace according to the resolve options you picked:
C:\Perforce\test\integ>p4 integ source target
//depot/integ/target#2 - integrate from //depot/integ/source#3
C:\Perforce\test\integ>p4 resolve -at
c:\Perforce\test\integ\target - vs //depot/integ/source#3
//Samwise-dvcs-1509687817/integ/target - copy from //depot/integ/source
C:\Perforce\test\integ>echo tampertampertamper >> target
C:\Perforce\test\integ>p4 submit -t -d "submitting tampered file"
Submitting change 190.
Locking 1 files ...
integrate //depot/integ/target#3
//Samwise-dvcs-1509687817/integ/target tampered with after resolve - edit or revert.
Submit aborted -- fix problems then use 'p4 submit -c 190'.
Some file(s) could not be transferred from client.
If you p4 edit the file, it's changed from a pure copy to an edit, and will be read from the workspace instead of from the source file:
C:\Perforce\test\integ>p4 edit target
//depot/integ/target#2 - reopened for edit
C:\Perforce\test\integ>p4 submit -c 190
Submitting change 190.
edit //depot/integ/target#3
Change 190 submitted.

Quartz Scheduling to delete files

I am using the file component with an argument quartz scheduler in order to pull some files from a given directory on every hour. Then i transform the data from the files and move the content to other files in other directory. After that I am moving the input files to an archive directory. When a file is moved to this directory it should stay there only a week and then it should be deleted automatically. The problem is that Im not really sure how can i start a new cron job because I dont really know when any of the files is moved to that archive directory. Maybe is something really trivial but I am pretty new to camel and I dont know the solution. Thank you in advance.
Use option "filterFile"
Every file has modified timestamp and you can use this timestamp to filter file that are older than 1 week. Under file component, there exist an option filterFile
filterFile=${date:file:yyyyMMdd}<${date:now-7d:yyyyMMdd}
Above evaluation comes from file language, ${date:file:yyyyMMdd} denote modified timestamp of the file in form (year)(month)(day) and ${date:now-7d:yyyyMMdd} denote current time minus 7 days in form (year)(month)(day).

In perforce how to check if any changes were made in the entire folder, and run a post processing script only if changes were made?

I am planning to create a cron job that does a p4 sync on a specific folder every day at a certain time and does some post processing of the files in the folder.
However, before doing the post processing I would like to check if the files in the folder differ from that of the perforce repository, and only if there are changes, I'd go ahead with the post processing.
How do I integrate a p4 diff with my csh script and if there's any other elegant way to check for differences and trigger the post processing.
In summary, I'm trying to achieve this:
if (check for differences in <my directory>) then
{ run my post-processing script }
else
{ dont run}
If you want to see if any new revisions have been added to the depot since your sync completed, you could run:
p4 have
in your workspace, and compare this to the output from:
p4 files
run against the corresponding depot files and/or directories.
Example:
jen#Jen: ~/workspaces/testing/depot/depot/testingjen#Jen:~/workspaces/testing/depot/depot/testing$ p4 have //depot/testing/...
//depot/testing/test#1 - /home/jen/workspaces/testing/depot/depot/testing/test
jen#Jen: ~/workspaces/testing/depot/depot/testingjen#Jen:~/workspaces/testing/depot/depot/testing$ p4 files //depot/testing/...
//depot/testing/test#2 - edit change 7445 (text)
Hope this helps,
Jen.

A simple way to save a file version to a child folder and generate/increment a log?

I looked to TortoiseSVN and TortoiseHG... bit too much for me and I don't want to setup a structure where the files will be saved. All I want is:
When saving a file, first saves the file.
Then if there isn't in file's folder a sub-folder called "History", it creates it.
Then Copies the file to "History" and gives it the first available number suffix as "_[version]".
Then, if is no txt file, in the file's folder, called "[filename].[extension]_Notes.txt", it creates it and adds a line with:
Version: [version] " of the " [filename] " saved at: " [date]
Now how would this run from any application? Dunno. Maybe have a button in the file save dialog?
I'm asking this because I'm just one guy working and not on huge projects and 99% of the time I would just like to have a localized versioning, set on a local sub-folder and a log to track the versions and dates.
Is this super easy with Tortoise and I'm being a mule?
Cheers

sync two vobs file (by clearfsimport) without checking in the updated file

I am using following command to sync B vob files from A vob
clearfsimport -master -follow -nsetevent -comment $2 /vobs/A/xxx/*.h /vobs/B/xxx/
It works fine. But it will check in all the changes automatically. Is there a way to do the same task but leave the update files in a check out status?
I want to update the file for B from A. Build my programme, and then re-cover the branch. So if the updated files is an check out status, I can do unco later. Well with my command before, everything is checked in. I cann't re-cover my branch then.
Thanks.
As VonC said, it's impossible to prevent "clearfsimport" to do the check in. And he suggested to use a label to recover back.
For me, the branch where I did "clearfsimport" is branched from a label.Let's call it LABEL_01. So I guess I can use that label for recovery. Is there an easy way (one command) to recover the files under /vobs/B/xxx/ to label LABEL_01 ? I want to do it in my bash script, so the less/easy the command is, the better.
Thanks.
After having a look at the man page for clearfsimport, no, it isn't possible to prevent the checkins.
I would set a label before the clearfsimport, and modify the config spec for the new version to be created in a branch (similar to this config spec).
That way, "re-cover" the initial branch would be easy: none of the new version would have been created in it.

Resources