How about naming it like this:

p4 integrate //depot/main/... //depot/main_branches/release98.2/...

I was just suggesting that if you simplify it enough for a branch graph to be understandable, you might be able to just name the directories in such a way as to give you enough info, too. Depends on what you use the branches for, though - a branch graph might be useful for figuring when major development branches were created and when/where they got merged back into a main development line. But, since the branches apply to sets of files and you can do arbitrary branching/merging of individual files, I guess you could ask for a branch graph of an individual (representative) file...then use some discipline in how you do branching/mergings so the branch graph of the single file would represent the entire group of files described by the branch spec.

Did that make sense? Being relatively new (well...a year with no major releases) to Perforce, we have used branching much.

It changes some values in the registry.

I forget the precedence of environment variables versus the 'p4 set' registry settings and 'p4 help set' says:

Currently, registry variable entries may be overriden by environment variables and (in some cases) flags on the command line.

[98.1 client/servers on NT have that misspelling of the word "overridden"]

but if you avoid using envars and set things with 'p4 set', it should be system wide. Actually, 'p4 set' has a '-s' switch to say whether or not the settings are system wide (HKEY_LOCAL_MACHINE) or per-user (HKEY_CURRENT_USER).

If you have a client view spec like:

//depot/main/... //CLIENT/main/...

then the "main/..." is relative to the 'Root' of the client view. That way, you can relocate your sources without having to go change all the entries in your client view spec. I've noticed that things start getting a little confused (as to what files you really "have" - I think it forgets that you have some files or some such - I haven't experimented enough with it to figure out the specifics) if you go editing the 'view'...especially if you've got some files checked out when you do it. I haven't verified it, but I imagine that changing the 'Root' of the client spec wouldn't have such an effect. All that helps if you have multiple entries in your client 'view'.

I think it also makes use of "template clients" easier. If you've got a view that you want to keep consistent, you can use that view as a template for creation of other clients, then just edit the 'root' setting to locate the client directory tree on a system.

So...I imagine you can use UNC paths (but haven't verified) for the 'root' setting, but I don't think the syntax for the 'view' specs are up to it yet (but don't know for sure). I wonder if it'd work to set 'root' to 'null', then in the 'view', have something like this:

//depot/main/... //CLIENT/X:/main/...

for an absolute path starting with a drive letter or

//depot/main/... //CLIENT/Server/Share/main/...

for a UNC path to the "main" subdir of \\Server\Share - is there an existing use for that path component that would make "Server" ambiguous when 'Root: null'?