[p4] Very big Perforce file : db.have

[David Faison]

If the goal is to minimize the amount of records stored in the Perforce
server DB, and the premise is that you are ONLY doing 'stateless'
synchronizations (i.e. 'p4 sync -f' type operations) then I think the
simplest answer is to use a host-less client (i.e. just leave the
'Host:' field empty in your client spec) and you can use it on any
machine. 

If all you ever do are stateless synchronizations, and all your machines
can utilize a common 'p4 root' directory,  then this technique is safe.

The same clientspec can even be used across windows and unix platforms
as long as you don't need to specify a particular drive for your windows
box (e.g. if your p4 root is "/home/user/myproject/", then issuing a "p4
sync -f" will drop files into your "c:\home\user\myproject" directory.
You are, however, restricted to using perforce paths (the windows path
"is not under client's root" when the root is stored in a unix format).

This does result in a record set being maintained - but only one set,
for any number of machines...

David Faison
 


-----Original Message-----
From: perforce-user-bounces at perforce.com
[mailto:perforce-user-bounces at perforce.com] On Behalf Of David Jones
Sent: Friday, August 11, 2006 12:55 PM
To: perforce-user at perforce.com
Cc: David Ferguson; Robert Cowham
Subject: Re: [p4] Very big Perforce file : db.have


On 11 Aug 2006, at 15:01, Robert Cowham wrote:

> It exists already - it is called "p4 print"!
>
> A perhaps more practical alternative is:
>
> p4 sync 			(syncs whole client workspace)
> p4 sync -k #0		("pretends" to sync whole workspace to zero rev,
> i.e. remove files)
>
> The latter command is the same as "p4 flush" in older releases. In  
> this
> instance it updates the db.have to remove all entries for the  
> synced files,
> and yet leaves the synced copies on disk. See command ref for more  
> info.

This reminds me of my favourite way to get a separate copy of a  
directory hierarchy from perforce and put it somewhere on my disk  
(underneath my client).  It uses an integ, edit, revert trick and  
goes more or less likes this:

# get a new changenumber with something like
printf 'Change: new\nDescription: hack' | p4 change -i
p4 integ -c XXX //depot/foo/bar/... spong/...
# spong must not already exist (and permissions yada yada)
p4 edit -c XXX spong/...
p4 revert -c XXX spong/...
# delete the change if you must
p4 change -d XXX

Now spong contains everything from //depot/foo/bar and the perforce  
server state is more or less unchanged.

drj



>
> Robert
>
>> -----Original Message-----
>> From: perforce-user-bounces at perforce.com
>> [mailto:perforce-user-bounces at perforce.com] On Behalf Of
>> Prakash Ranade
>> Sent: 10 August 2006 23:53
>> To: David Ferguson; jgrills at junctionpoint.com; Andres
>> Fuentes; perforce-user at perforce.com
>> Subject: Re: [p4] Very big Perforce file : db.have
>>
>> Hello Perforce Folks,
>>
>> Speaking on the "db.have" file growth issue.
>>
>> Can we have a perforce command or argument in "p4 sync",
>> where perforce will not store the "the revision record"
>> synced to the client in the "db.have"?
>> Let's say "p4 sync -a" to avoid tracking the "have-list" of
>> the client.
>>
>> This could be very helpful in controlling the growth of the  
>> "db.have".
>> Example, build system churns the build and store the
>> change/label information, but never interested to store the
>> "the revision record" of each files synced to the build client.
>>
>> Regards,
>>
>> Prakash Ranade
> _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user
>
_______________________________________________
perforce-user mailing list  -  perforce-user at perforce.com
http://maillist.perforce.com/mailman/listinfo/perforce-user