perforce - sync multiple files at specific revisions quickly

Question

Is there a way to synch multiple files at specific revisions quickly.

For example specify a list of files and revisions as follows: foo#1 bar#4 baz#3

I could sync these in a foreach loop in he shell individually - but this would be slow for large lists. So is there a quick/batch way of doing this?

I do know about using labels - but in this case we must assume no label existed for this set of files and revisions - the only source we have is the list as shown above.

Pompon

It's not clear why you're ruling out the use of labels; they seem like the cleanest and clearest way to approach this problem. It also seems like you're assuming certain approaches would be slow without actually timing them. However, there certainly are other approaches; for example, you can pass all the file#rev arguments to a single sync command, for example by writing them to a file and specifying the file with -x. – Octodecillion

Thanks ryan, that may be all I neeed. I assume I could only pass at most a few files on the command line (limited by the max command line length). If the -x option works, then it should solve the problem. – Pompon

The reason labels may not be suitable is because I was advised against using them for performance reasons. Our administrators were told by the vendor that using lots of labels on huge depots can affect general performance. As the use-case I have is for a small project that interacts with the huge central depot, I don't want to risk affecting performance for everyone. Thanks again for the -x tip! – Pompon

Why do you want to do this, are you sure a specific changelist number does not have all these revisions at the correct point in time? – Hu

@TobyAllen, yes for this use-case there is no way of knowing ahead of time the files that need to be updated, so as a result no changelist can exist for them. – Pompon

But what's the use case why would you need to get a specific set of version of files that aren't related in any other way, there must be some reason they are related? – Hu

@TobyAllen the use-case is as follows: We use P4 for HW design, so it is not a standard SW devel model. We need tags that contain specific versions of files (rather than a changenumber) because at times in a HW you must go back and tweak the versions of some of the items contained in that tag (for reasons I won't go into, but it is valid). We could use labels, or tags based on labels, but were advised this can have adverse effects on depot performance. Instead, we can simply dump the workspace state using 'p4 have' to a text file, and then edit / sync it later using the method described here. – Pompon

Answer 1

You can use a file as an argument with the -x global option flag, as Bryan mentioned in his comment.

EXAMPLE - sync

-- Notice the file contents of 'syncfile.txt' with three filenames, at specific revisions.

$ cat syncfile.txt
foo#1
bar#4
baz#3

-- The client workspace currently has all the head revisions.

$ p4 have //depot/test/...
//depot/test/bar#5 - /home/admin/depot/test/bar
//depot/test/baz#4 - /home/admin/depot/test/baz
//depot/test/foo#5 - /home/admin/depot/test/foo

-- Now the file is passed as an argument with the 'sync' command, and the updates display

$ p4 -x syncfile.txt sync
//depot/test/foo#1 - updating /home/admin/depot/test/foo
//depot/test/bar#4 - updating /home/admin/depot/test/bar
//depot/test/baz#3 - updating /home/admin/depot/test/baz

-- Running the 'have' command again to verify that indeed the specific revisions were synced.

$ p4 have //depot/test/...
//depot/test/bar#4 - /home/admin/depot/test/bar
//depot/test/baz#3 - /home/admin/depot/test/baz
//depot/test/foo#1 - /home/admin/depot/test/foo

EXAMPLE - ADD

-- Notice the file contents of 'addfiles.txt' with three filenames.

$ cat addfiles.txt
who
me
you

-- The file is passed as an argument with the 'add' command, and the files listed are added.

$ p4 -x addfiles.txt add
//depot/test/who#1 - opened for add
//depot/test/me#1 - opened for add
//depot/test/you#1 - opened for add

Here are examples of how to use the '-x' flag in documentation:

http://answers.perforce.com/articles/KB_Article/The-x-Flag

http://answers.perforce.com/articles/KB_Article/Adding-a-Directory-Tree

http://answers.perforce.com/articles/KB_Article/Integ-Using-the-x-Global-Option

http://www.perforce.com/perforce/doc.current/manuals/cmdref/global.options.html

Bahamas

Thanks very much for this - it is very clear and should work for my usecase. I will try it as soon as I'm back in work. – Pompon

Answer 2

After discussion in comments, I understand a little better now.

If labels do what you want (basically sync to a set of files in a specific workspace at a point in time) then use them.

Where the idea of labels affecting depot performance comes in, is using labels incorrectly. Many companies and dev groups that moved from VSS (and some other systems) to Perforce used Labels in perforce like they used them in VSS - basically to mark a point in time. This allowed you to set a label for a version and go back to that if you wanted. In perforce every changelist is a point in time.

Labels in perforce don't work like this and when they are used to basically duplicate a changelist, and often a build system will create a label everynight, then they are a huge waste of performance.

In your case Labels are the correct solution, I suggest you read up on them and use them if they work for your scenario.

Hu

Thanks for this in-depth answer. The request not to use labels comes from our database admin - again because our database is huge (not sure how big, but in the 100s of GBs / TBs), so anything with the potential to degrade performance is simply not allowed. Given that, while labels may be the right solution, I cannot use them. The solution with p4 have + the -x option will work for my use-case without having to run the risk of incurring the wrath of admins. Thanks again for the help. – Pompon