[p4] How to use p4wsad?

Mon Feb 20 13:48:46 PST 2006

> -----Original Message-----
> From: West, Larry [mailto:Larry_West at intuit.com] 
> 
> One nice feature to note is the "Label Decorations" preference (Menu:
> Window, Preferences..., Team, Perforce).   This lets you set 
> up the little
> green dots, blue or red checkmarks, et cetera, decorating the 
> file's icon in
> the project list.   (I've got mine more or less like P4Win's.)

I've now gotten it to the point where I can do things like "revision
history" on a file, and it will show the p4 revision history on the
file.  That confirms that it's mostly working.  However, I can't get
this label decoration thing working.  I've set all 4 "file decoration
icons" settings to non-None.  I'm not sure what I should be seeing now.
When I view the package tree in the Package Explorer in the Java
perspective, the icons don't appear to be different.  For example, I
have one XML file checked for edit.  The icon on it is a small sheet
with an X on it.  This is the same icon used with the other XML files.
I don't see any file icon that seems to have p4 metadata on it.

> -----Original Message-----
> ------------------------------
> 
> Message: 2
> Date: Fri, 17 Feb 2006 13:02:52 -0800
> From: "Karr, David" <david.karr at wamu.net>
> Subject: [p4] How to use p4wsad?
> To: <perforce-user at perforce.com>
> Message-ID:
> 	<0C260F619E428642BFA6380177C3ADF302192549 at exmsea005.us.wamu.net>
> Content-Type: text/plain;	charset="us-ascii"
> 
> I have Eclipse 3.1.1, and I've installed the p4wsad plugin 
> from the perforce site.  The funny thing about the 
> documentation for this plugin is that it doesn't appear to 
> actually say what it does, or how to tell whether it's doing 
> anything.  Did I miss some information that would describe 
> this?  I'm not sure what I can do with this after I've 
> installed it.  I normally use p4win or p4 cmdlines for p4 
> operations, but I'd like to have the ability to do things 
> directly in Eclipse.
> 
> 
> 
> ------------------------------
> 
> Message: 3
> Date: Fri, 17 Feb 2006 17:53:03 -0800
> From: "Nick Dor" <Nick.Dor at zoran.com>
> Subject: Re: [p4] NFS mounted depot
> To: <perforce-user at perforce.com>
> Message-ID:
> 	<9162A32EBBB6ED428BC932239A30D77105D58C16 at zcoex.ZCO.Zoran.COM>
> Content-Type: text/plain;	charset="us-ascii"
> 
> One key point regarding NVIDIA's NetApp implementation is 
> that their metadata files (db.*) are stored on SAN, thus they 
> are not using NFS for the journal and db files and still 
> within Perforce support's recommended best practices.
> 
> - Nick
> 
> -----Original Message-----
> From: perforce-user-bounces at perforce.com
> [mailto:perforce-user-bounces at perforce.com] On Behalf Of 
> Weintraub, David
> Sent: Friday, February 17, 2006 11:13 AM
> To: Smith, Jeff; perforce-user at perforce.com
> Subject: Re: [p4] NFS mounted depot
> 
> I had a long talk about this issue with the Perforce support. 
> Most corporate Unix environments don't backup local drives 
> and normally don't even give you access to the local disks. 
> Everything is NFS mounted except for the OS, so if what 
> Perforce states is true, you couldn't use Perforce in many 
> corporate environments.
> 
> I had read the documentation and knew about the locking issue 
> which would affect the database, but couldn't understand how 
> it would affect the RCS files. Especially considering that 
> all writes to these files come from the same server.
> 
> I specicially asked you placed the *.db files on a local 
> drive, could everything else live on NFS. The Perforce 
> support person told me that the journal and the license file 
> must be local, but that the checkpoint file and the RCS files 
> could in fact be NFS mounted.
> 
> We also discussed backup strategy since I *might* be able to 
> convince my sysAdmin department to give me local storage for 
> the *.db and journal files, but I know they won't do local 
> backups at all. Perforce explained to me that the database 
> files and journal don't have to be backed up since that's 
> what the checkpoint really does, and the checkpoint file 
> could be stored on NFS.
> 
> Their only recommendation was to store the journal and *.db 
> files on separate drives controlled by separate controllers. 
> That way, if one controller fails and completely damages all 
> of the disks attached to it, you could rebuild the needed 
> information from the other disk drive.
> 
> Perforce has a conference paper on their system by NetApps 
> talking about their experience using Perforce with NetApps.
> 
> <http://www.netapp.com/library/tr/3372.pdf>
> <http://www.perforce.com/perforce/conf2001/geiger/wprmg.html>
> 
> 
> -----Original Message-----
> From: Smith, Jeff [mailto:jsmith at medplus.com]
> Sent: Friday, February 17, 2006 1:18 PM
> To: Weintraub, David; perforce-user at perforce.com
> Subject: RE: [p4] NFS mounted depot
> 
> Did they explain the discrepancy between that position and 
> the documentation?  I just got back a reply from Perforce 
> support that we should avoid NFS at all costs.
> 
> Jeff
> 
> -----Original Message-----
> From: Weintraub, David [mailto:david.weintraub at bofasecurities.com]
> Sent: Friday, February 17, 2006 1:01 PM
> To: Smith, Jeff; perforce-user at perforce.com
> Subject: RE: [p4] NFS mounted depot
> 
> 
> > Should we be wary of moving our depot files, served by a 
> Linux p4d, to
> an NFS mount?
> 
> I was the one who asked about this very issue and got 
> official word from on high that the RCS files and the 
> checkpoint files can be stored on NFS mounted drives. 
> However, the journal and database file need to be stored on 
> local drives on non-Solaris systems due to this locking 
> issue. Perforce also recommend storing your journal and db.* 
> files on two separate drives that use separate disk controllers.
> 
> The reason for putting the database and journal on two 
> separate disk controllers is fairly straight forward: If the 
> database files get corrupted, they can be rebuilt using the 
> journal. If the journal file gets hosed, it will 
> automatically be rebuilt when Perforce is restarted. Your 
> only real issue is if your Perforce server itself gets 
> destroyed and both the Journal and the database files become 
> damaged. Then, you have to restore using your checkpoint 
> files, and that means losing all of your transactions since 
> the last checkpoint operation.
> 
> By the way, Perforce recommends never using NFS mounted drives for the
> db.* and journal files. For performance reasons, these should 
> always be on local disks whenever possible.
> 
> -----Original Message-----
> From: perforce-user-bounces at perforce.com
> [mailto:perforce-user-bounces at perforce.com] On Behalf Of Smith, Jeff
> Sent: Friday, February 17, 2006 12:29 PM
> To: perforce-user at perforce.com
> Subject: [p4] NFS mounted depot
> 
> There was a thread earlier in which someone indicated that 
> the db.* files should not be mounted on NFS except using 
> Solaris 2.6 but that the depot should be no problem.  The 
> Admin guide actually says
> 
> "Some issues still remain regarding file locking on 
> non-commercial implementations of NFS (for instance, Linux 
> and FreeBSD). On these platforms, store your journal, log, 
> depot, and db.* files on a drive local to the server machine, 
> not on an NFS-mounted volume."
> 
> Should we be wary of moving our depot files, served by a 
> Linux p4d, to an NFS mount?
> 
> Jeff
> 
> _______________________________________________
> 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
> 
> 
> 
> ------------------------------
> 
> _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com 
> http://maillist.perforce.com/mailman/listinfo/perforce-user
> 
> 
> End of perforce-user Digest, Vol 14, Issue 21
> *********************************************
> 