Does labelsync actually sync a file from the depot?
or does it only require a file name?
If it does sync, then is there any alternate command like flush that wud work similar to labelsync but faster(i.e without syncing the files) ?
Please Help
Labelsync modifies the set of files associated with a label, it does not sync a file from the depot. It is quite different from sync. There is a flush command: http://www.perforce.com/perforce/doc.current/manuals/cmdref/flush.html#1040665 Flush is similar to sync but it does not actually transfer the files.
I have no idea what sort of command you are trying to run, since flush and labelsync are used for two very different purposes, and both run very fast.
Perhaps you are looking for: http://www.perforce.com/perforce/doc.current/manuals/intro/01_intro.html#1067317
Related
I wonder if there is any way i could retrieve all changes i made to my various configuration files since install(residing in /etc and so on) in one shot?
I imagine some kind of loop, that uses 'diff' to compare all those files to a 'standard installation' of ubuntu. Output should be a single file with information regarding the changes that were made and a timestamp.
Perhaps there is even a way to put all that in a script and let it run regularly to automatically keep track of future config file changes.
If the files are already modified, I guess your only option is to diff your files with a fresh install. Keep in mind some files might be specific to you computer, I'm thinking of files that can hold device-specific values like your mac address udev/rules.d/70-persistent-net.rules, your drives uuid /etc/fstab, etc.
If you're planning this ahead, there are at least two options you can consider:
use a VCS such as git.
use a filesystem that keeps a complete history of the changes made.
I want to get a list of changes for a perforce branch like:
p4 -t -L //mydepot/library1/v1.0/...#2017/03/27,#now
That is, a list of all changes this week with description. But I also want a list of the files, as in
files in one changelist:
p4 files #=123456
This seems like it needs script, but anyone know of a perforce method?
If the returned changeset collection is large, will the server be adversely impacted by querying every changeset afterwards?
p4 -Ztag -F "describe -s %change%" changes //mydepot/library1/v1.0/...#2017/03/27,#now | p4 -x - run
The answer to the performance question depends on how many is "large" (how many changes/files are we talking about) and your server hardware.
My guess is that with a "normal" server and "normal" usage you'll be fine but if we're talking about a few billion changes with a few billion files each, yeah, those commands will take a while. If we're more in the hundreds or thousands range, meh.
You asked a bunch of questions in one question, so here's a bunch of answers in one answer.
Use the p4 changes command to get a list of changes of interest.
Use p4 describe -s or p4 files #= to get a list of the files in each change.
Yes, to combine these two sets of data you need a script, but it can be a remarkably short script. You can use the p4 command-line aliases feature to write such a script, or you can use your favorite scripting language. There are lots of examples of such scripts on the web.
The server will end up have to perform multiple commands, but these particular commands are ones that the server does very efficiently. I suspect that it won't be so much that the server will have a problem computing the output, but that you will have a problem reading all that output. In other words, don't run a script that produces more output than you want to read.
Is it possible to map the same part of a depot to two (or more) different places?
//depot/branches/foo/... //my_client/foo/...
//depot/branches/foo/... //my_client/foo1/...
The reason I want this is to be able to make unrelated and non-overlapping changes to the same file(s) simultaneously.
(If they were different files, I could simply use different change-lists in a single mapping, of course.)
A given client view can only have one of a given depot file at a given time. That said, here are three possible ways to make two different changes to the same file at the same time:
1) Do your two changes need to both exist on your client machine simultaneously? If not, when you want to pause work on your first change, "shelve" it, revert your local file, and then make your second change. You can have any number of "shelved" versions of a file (in different changelists) associated with a single client, but only the "open" file is actually present in the workspace.
2) Do you in fact need both files on your machine, but not necessarily need to run Perforce commands on them simultaneously (like merge changes between them, diff them vs each other, submit them both as a single change, etc)? If so, having multiple client specs is a good option. Make sure they have different roots (hence different local filesystem locations), and use P4CONFIG files so that you'll automatically use the client spec that matches your working directory.
3) Do you need both files and want the ability to version different sets of changes to them simultaneously, diff the two variants, and merge changes between them? If so, you want to make a new branch. Do:
p4 integ //depot/branches/foo/... //depot/branches/foo1/...
p4 submit
Now there are two sets of files in the depot and in your workspace; you can make independent changes to them, and use "p4 integ" later to merge those changes between them (in either direction) as desired.
Bryan's suggestion is a good option for what you would like to accomplish.
In terms of overlay mappings in a client workspace, Perforce allows you to map multiple depots to the same workspace location as documented here:
http://www.perforce.com/perforce/doc.current/manuals/p4guide/chapter.configuration.html#configuration.refine_workspace.map_diff_depot_locations
There is a very useful "remote copy" feature in s3cmd sync where any duplicate copies of a file existing in the source directory will not be transferred more than once to the S3 bucket, but a remote copy will take place instead, reducing the bandwidth taken for the transfer.
I have been searching for a similar solution to do a similar file transfer between 2 Linux servers. I've used rsync many times in the past, doesn't look like it has an option for this but perhaps I have missed something.
Simple example :
/sourcedir/dir1/filea
/sourcedir/dir1/fileb
/sourcedir/dir1/filec
/sourcedir/dir2/filea
/sourcedir/dir2/filed
/sourcedir/dir2/filee
/sourcedir/dir3/filea
/sourcedir/dir3/filef
/sourcedir/dir3/fileg
With a typical transfer, filea would be transferred across the network 3 times.
I'd like to transfer this file only once and have the remote server copy the file twice to restore it to the correct directories on the other side.
I need to perform a sync on a large directory with many duplicates in the fastest time possible.
I know it would be possible to script a solution to this, but if anyone knows an application with this native functionality then that would be great!
Thanks
A very basic question about branching and duplicating resources, I have had discussion like this due to the size of our main branch, but put aside it is great to know how this really works.
Consider the problem of branching dozens of Gb.
What happens when you create a branch of this massive amount of information?
Am reading the official doc here and here, but am still confused on how the files are stored for each branch on the server.
Say a file A.txt exists in main branch.
When creating the branch (Xbranch) and considering A.txt won't have changes, will the perforce server duplicate the A.txt (one keeping the main changes and another for the Xbranch)?
For a massive amount of data, it becomes a matter because it will mean duplicate the dozens of Gb. So how does this really work?
Some notes in addition to Bryan Pendleton's answer (and the questions from it)
To really check your understanding of what is going on, it is good to try with a test repository with a small number of files and to create checkpoints after each major action and then compare the checkpoints to see what actual database rows were written (as well as having a look at the archive files that the server maintains). This is very quick and easy to setup. You will notice that every branched file generates records in db.integed, db.rev, db.revcx and db.revhx - let alone any in db.have.
You also need to be aware of which server version you are using as the behavior has been enhanced over time. Check the output of "p4 help obliterate":
Obliterate is aware of lazy copies made when 'p4 integrate' creates
a branch, and does not remove copies that are still in use. Because
of this, obliterating files does not guarantee that the corresponding
files in the archive will be removed.
Some other points:
The default flags for "p4 integrate" to create branches copied the files down to the client workspace and then copied them back to the server with the submit. This took time depending on how many and how big the files were. It has long been possible to avoid this using the -v (virtual) flag, which just creates the appropriate rows on the server and avoids updating the client workspace - usually hugely faster. The possible slight downside is you have to sync the files afterwards to work on them.
Newer releases of Perforce have the "p4 populate" command which does the same as an "integrate -v" but also does not actually require the target files to be mapped into the current client workspace - this avoids the dreaded "no target file(s) in client view" error which many beginners have struggled with! [In P4V this is the "Branch files..." command on right click menu, rather than "Merge/Integrate..."]
Streams has made branching a lot slicker and easier in many ways - well worth reading up on and playing with (the only potential fly in the ointment is a flat 2 level naming hierarchy, and also potential challenges in migrating existing branches with existing relationships into streams)
Task streams are pretty nifty and save lots of space on the server
Obliterate has had an interesting flag -b for a few releases which is like being able to quickly and easily remove unchanged branch files - so like retro-creating a task stream. Can potentially save millions of database rows in larger installations with lots of branching
In general, branching a file does not create a copy of the file's contents; instead, the Perforce server just writes an additional database record describing the new revision, but shares the single copy of the file's contents.
Perforce refers to these as "lazy copies"; you can learn more about them here: http://answers.perforce.com/articles/KB_Article/How-to-Identify-a-Lazy-Copy-of-a-File
One exception is if you use the "+S" filetype modifier, as in this case each branch will have its own copy of the content, so that the +S semantics can be performed properly on each branch independently.