How do I add a client without doing a full "get"?

[BillReesbreeze at yellowstone.esd.sgi.com]

Would it be reasonable to create a client on the fast side of the WAN,
and then just change the client's root to reflect the location on the
slow side of the WAN?

> -----Original Message-----
> From:	Christopher Seiwald [SMTP:seiwald at perforce.com]
> Sent:	Friday, October 03, 1997 7:58 AM
> To:	perforce-user at perforce.com
> Subject:	Re: How do I add a client without doing a full "get"?
> 
> |
> |  > > This is a pain over a LAN, and an an absolute disaster over a
> WAN.
> |  > > Can't the client check the contents of the local disk and only
> download
> |  > > the files which are different?
> |
> 
> OK OK -- time for a little undocumented behavior.
> 
> There is a variant of "p4 get" called "p4 flush" that _pretends_ to do
> a "get" but doesn't actually transfer any files.  All it really does
> is
> fill the server with the information to indicate the client has the
> files.
> 
> There are two ways (I can think of) to use this to "bootstrap" a big
> client at the far end of a slow link:
> 
> 1.	Copy the contents of another client that is also at the far
> 	end of the slow link, and then use "flush" to copy the that
> 	client's "have" list.
> 
> 		% cp -r _other_clients_files_ .
> 		% p4 flush @other_client_name
> 
> 	The "@other_client_name" is using the other client's "have"
> 	list as if it were a label (clients and labels work the same
> 	this way in Perforce), and so the "flush" essentially copies
> 	the other client's "have" list.
> 
> 	You can run into trouble if the other client has files opened
> for
> 	edit, though, as the "have" list doesn't reflect that.
> 
> 2.	Copy the files you think you are supposed to have into your
> 	client workspace, use "flush", and then use the variants of
> 	"p4 diff" to fix what you got wrong.
> 
> 		% cp -r _some_set_of_files_ .
> 		% p4 flush
> 		% p4 refresh `p4 diff -se` `p4 diff -sd`
> 
> 	The "flush" in this example brings your client's "have" list up
> 	to the head revisions.  The refresh command forcibly replaces
> 	your local files with the files Perforce thinks you have, and
> 	the diff commands provide the lists of files that are out of
> 	sync.  'diff -se' compares file checksums to see what is
> different,
> 	and 'diff -sd' just looks for missing files.  Both of these are
> 	network efficient.
> 
> 	This mechanism is pretty foolproof, except that its final
> 	performance (how much refresh has to refresh) depends on how
> 	accurately you populated your client workspace. 
> 
> Note that this is making the user do what the SCM system should do --
> populate client workspaces and keep track of them -- and is only
> justified
> when you have lots of copies of data on the wrong side of a slow link.
> Even then, this trick is mostly for people who want to get a jump
> start
> on using Perforce for the first time, rather than launching their
> initial
> "gets" and night and coming back in the morning.  On a daily use
> basis,
> the amount of traffic is comparatively small and almost never worth 
> circumventing the system.
> 
> On a side note, we plan on coming up with a technote that lists these
> otherwise undocumented commands and options, so that we are sure
> customers
> get to use the same system we do :-).
> 
> Christopher