[p4] preventing use of same client on 2 different computers
greg_spencer at acm.org
Mon Oct 25 07:15:32 PDT 1999
I agree that it should be possible to tie a client to a machine, to help
with the learning curve. However, one legitimate use of multiple machines
using the same client is when you are working from work and from home, and
can take a removable media with you (Jaz drive or removable hard drive). In
this case, you can use a slow link at home, and a fast link at work, and not
have to sync large files over the slow link, or to synchronize clients
somehow. Having the same client on both machines is correct conceptually,
because it *is* the same client (just think of the client as being on the
removable media, instead of on a machine).
Also, in binding the clients to a machine, one should not be prevented from
having multiple clients on the same machine. One developer I knew worked on
several different projects simultaneously, and to keep things straight (open
change lists, etc), he created different clients for each project on his
machine. It worked very well for him.
If you did persuade perforce to include this feature, I would want it off by
default, and it should be switchable on a per-user basis (of course).
----- Original Message -----
From: Stephen Vance <steve at vance.com>
To: <perforce-user at perforce.com>
Sent: Saturday, October 23, 1999 5:36 PM
Subject: Re: [p4] preventing use of same client on 2 different computers
> I, too, would like to see the ability to tie a client to a machine, and
> requested this from Perforce. I agree that in the Unix world, NFS
> create a homogenous user environment is a good idea for more reasons than
> Perforce clients. The comparable mechanism in the Windows world is drive
> However, these in themselves do not address issues of a heterogenous
> environment. NFS for Windows and samba for Unix can help, but the basic
> filesystem addressing syntax is different. And this doesn't even take
> account the Mac and others.
> People make mistakes, and beginners make even more mistakes. I have run
> this as a fairly frequent beginner mistake, despite specific coaching to
> Not to mention that sometimes you want to establish that sharing clients
> between machines is bad policy. In fact, this kind of sharing is contrary
> Perforce's best practice recommendations. I have only found one situation
> which this is not a good recommendation, and that is portability builds of
> tentative fix for which exposure by submission is not appropriate (shared
> branch, no branch, etc.).
More information about the perforce-user