views:

754

answers:

3

If you do a sync in perforce it can happen, very often, to do nothing even if it should. If you do a forced sync (sync -f) it will definitely sync all the files from the server blindly and this is unacceptable if you have a big project.

The question is how can you do damn sync?

+10  A: 

The key part to your question is "even if it should". Without fail, in all my (too) many years of experience with Perforce, users who revert to forced syncs habitually, because a normal sync does not do what they expect, are not using Perforce correctly.

You must let Perforce manage your hard disk for you - the server knows which versions of which files you have, and so a normal sync just gets what it needs. If it fails, then that is almost without exception a sign that the user is modifying, deleting, adding, renaming files outside of Perforce (e.g. in Explorer).

Sometimes you may get a system funny (i.e. PC fault, ) that causes this, so it is not necessarily the users fault. But these are very rare - hence my "habitually" qualifier above.

If you think, hand on heart, that you are not doing anything out of the ordinary, then start to look at what other processes could be tweaking these files. E.g. does you build system do something odd, and try to modify files as it builds? Do you have an open network share that perhaps someone else is inadvertently poking? Do you have a backup system that is interfering?

Hope that helps.

Greg Whitfield
Perforce associates which versions of which files you have with your each client spec. This info is kept on the server with each client spec - in what it calls its "have list". Shared clients are not typical user practice. They are allowed by Perforce to enable particular usage scenarios. But if you are working on different machines, then that is handled by having a client spec per machine. It's exactly what they were designed for.
Greg Whitfield
Let's say you have a build farm - do you want to create a workspace(clientspec) for each computer in the farm?
Sorin Sbarnea
Yes, a client spec per machine would be advisable in most circumstances. You can automate their creation, however, so it's not as painful as you may think.
Greg Whitfield
Greg, can you provide some hints on this? I would like to find a way of following your suggestion but using an existing clientspec as a template and if someone is updating the original clientspec it script will update the clientspec generated.
Sorin Sbarnea
Most scripting can be performed easily with the command line p4 client. You can pipe text in, or, in the case of p4 client, the -t option allows you to provide a template. Try p4 help client for a first look. There are also API's to Perforce (Python, .net etc) - see Perforce website.For your last requirement, you can add a trigger to Perforce that will invoke a script/command if a client spec is changed. You could use this to regenerate the others - but think about whether you need this to happen immediately, or if you would be better served with an explicit "Publish" option.
Greg Whitfield
+3  A: 

If you create an inconsistency, where perforce looses track of what is going on in your workspace, you should use the "Reconcile offline work..." function (in P4V).

This will run a folder diff and tell you what options you have to resolve the inconsistencies.

In general, make sure that you always check out files explicitly through perforce (open for edit). This feels strange if you are used to other systems.

VoidPointer
Sorry but I'm not aiming to use the visual client for this. For the same project I sync files from 6 different perforce servers so only a batch solution is acceptable - I don't want to repeat the process manually.
Sorin Sbarnea
+2  A: 

As mentioned by the other answers, you need to create a separate client (workspace) for every "instance" of a directory tree synced from the depot.

If you want to force-sync only those files that have changed from the depot:

p4 diff -se ... | p4 -x - sync -f
p4 diff -sd ... | p4 -x - sync -f

Warning: that will overwrite any locally changed files (in the current directory and subdirectories).

If instead you edited some files and forgot to open them for edit first, you can do this:

p4 diff -se ... | p4 -x - edit

which will open for edit any file that's different from the depot.

And this:

p4 diff -sd ... | p4 -x - delete

will open for delete any file that was locally deleted.

Heath