[p4] How to list stale client spec's

[Jeff Grills]

I've been using perforce for quite a few years, but I've never found myself
worrying about how long a file was open nor stale opened files.  Maybe it's
just that I expect developers to be aware of what files they have out and
why.  If a client is in active use, developers using GUIs (which is most of
them?) will see what files they have checked out, and developers using the
command line are typically more advanced and will issue "p4 opened"
occasionally and notice the open files.  If the client isn't used very
often, then at some point the automated client purging system kicks in and
reminds the user about the client, and the email reminder could even contain
the list of opened files on that client.

Stale clients, on the other hand, are easy to forget.  Many organizations I
know name p4 clients with the machine name that is using the client, and
it's easy to retire an old machine and forget to remove that perforce
client.  The client languishes with potentially hundreds of thousands of
records in db.have.  That can cause a perforce performance nightmare,
especially on older server versions.  At one place I worked, our db.have
file was over 26gb after being freshly rebuilt from a checkpoint.  I've seen
the db.have file drop by 7gb or more when we've axed all the stale clients
and rebuilt the databases.

I'd never delete a client without warning its owner first.  The system we
had would nag the user for a couple weeks before deleting the client.  If
you still wanted the client, all you simply had to do was perform some
operation using the client (even a simple "p4 opened" - you don't even need
to change the file system contents) and it's access time would be updated
which would make the automated system stop pestering you for several months.
Another thing the automated system has going for it is that it doesn't
discriminate based on the user - when I used to do purge clients by hand by
talking to the users with stale clients to see if they could be removed,
some of those users would be managers in the company who were quite busy and
didn't want to deal with it but wouldn't let you delete the client either,
and the client would just sit there unused forever.  With the automated
system, the burden is placed on the end perforce user regardless of their
position, and if they want to keep the client they have to perform some
action to keep it.

j


> -----Original Message-----
> From: Weintraub, David [mailto:david.weintraub at bofasecurities.com] 
> Sent: Thursday, October 19, 2006 7:55 AM
> To: jgrills at junctionpoint.com; Helck, Christopher; 
> perforce-user at perforce.com
> Subject: RE: [p4] How to list stale client spec's
> 
> The main problem really isn't stale clients, but stale opened files.
> This happens all the time where a developer opens a file for 
> editing, but doesn't want to commit changes. For example, the 
> developer opens a file to change the port configuration of an 
> application, so they can test it on their machine without 
> affecting anyone else. They certainly don't want to submit 
> their change, and end up changing the port number in the 
> actual application.
> 
> Imagine a client/server type of application. I might run a 
> server instance on port 8080 while the developer next to me 
> runs it on port 8081. I open the file where the port is set 
> and change the port for my own personal use. However, I 
> certainly don't want to submit this change and change it in 
> the actual application. What happens if the file where the 
> port is set has changed, but I'm still doing my development 
> based upon the older version that I originally opened.
> 
> What I should really be interested in are files that have 
> been opened for more than a certain length of time, but their 
> changes have never been committed.
> 
> I'm not overly concerned with obsolete clients since they 
> really don't affect Perforce's overall performance or hinder 
> development. I personally have about a dozen clients for 
> various projects, but many of those projects haven't changed 
> in months. For example, I have a client workspace for the 
> various cronjob files on our system. The last access time on 
> my client is almost 80 days. Is this client obsolete? Not 
> really, there just hasn't been a need for me to change any of 
> the cronjob files. I'd be a bit upset, if I needed to make a 
> change to the cronjobs, but discovered that somebody deleted 
> my client because they thought it was obsolete. I can even 
> imagine a developer saying "to hell with this", and making 
> the change outside of Perforce.
> 
> However, let's say instead I had a file that had been opened 
> on this cronjob client for three weeks. This could mean I 
> forgot to submit my changes or that I was doing some 
> experimenting, and didn't want to submit the file. If it was 
> the first instance, informing me that I have a stale opened 
> file is important because I need to commit this change.
> 
> Having a stale opened file is bad even if I had simply played 
> around with the cronjob files, but didn't want to submit my 
> change. Let's say the file I changed was changed by someone 
> else. When I do my development, and I do a p4 sync, I won't 
> get the latest changes.
> Instead, I am basing my development on an older version of the file.
> Even worse, I am basing my development on a version of the 
> file that I had corrupted.
> 
> So, it isn't stale clients that worry me since they really 
> don't affect anything except clog up my "p4 clients" listing. 
> We force our clients to start with the developer's ID, and we 
> delete the developer's clients when the developer leaves. 
> Both of these make having a lot of clients manageable. The 
> real problem are old opened files. These really can 
> negatively affect development.