[p4] preventing use of same client on 2 different computers

[Glenn Kasten]

We've just converted to Perforce, and some of our new users are making the
mistake of trying to use the same client on different computers. Unless the root
directory is a share or NFS mount, this will confuse the p4 server.

I would like to suggest that a new field be added to the client form, which is
the computer name. By default it would be the name of the computer the client
was created on. Users could change it to be a list of computers, or any computer
if they know it is safe. This would prevent users from accidentally using a
client on the wrong machine.

Glenn

[Piaw Na]

This is a one-time issue, I bet. I've never seen it happen here, since we
started with Perforce (nice thing about being a startup :-). Basically, we
made it work by using a naming convention (login-machinename-project) and
then asking everyone to use .p4config files.

Piaw

-----Original Message-----
From: Glenn Kasten [mailto:***@peerless.com]
Sent: Wednesday, October 20, 1999 11:23 AM
To: perforce-***@perforce.com
Subject: [p4] preventing use of same client on 2 different computers


We've just converted to Perforce, and some of our new users are making the
mistake of trying to use the same client on different computers. Unless the
root
directory is a share or NFS mount, this will confuse the p4 server.

I would like to suggest that a new field be added to the client form, which
is
the computer name. By default it would be the name of the computer the
client
was created on. Users could change it to be a list of computers, or any
computer
if they know it is safe. This would prevent users from accidentally using a
client on the wrong machine.

Glenn



_______________________________________________
perforce-user mailing list - perforce-***@perforce.com
http://maillist.perforce.com/mailman/listinfo/perforce-user

[Rick Macdonald]

On Wed, 20 Oct 1999, Glenn Kasten wrote:

> We've just converted to Perforce, and some of our new users are making
> the mistake of trying to use the same client on different computers.
> Unless the root directory is a share or NFS mount, this will confuse
> the p4 server.
>
> I would like to suggest that a new field be added to the client form,
> which is the computer name. By default it would be the name of the
> computer the client was created on. Users could change it to be a list
> of computers, or any computer if they know it is safe. This would
> prevent users from accidentally using a client on the wrong machine.

...by default it should allow any host, as it does now!

I wouldn't want this. We simply put the hostname in the client name.

I find it handy to switch to various clients and see what they're sync'd
to, run preview syncs to see what is out-of-date, etc, from any machine or
even from home while dialed up to the office.

...RickM...

[Eric Scouten]

Agreed. I wouldn't want it either. We use the same hostname -> client name
convention that Rick just described.

It's a one-time thing; walk your users through it correctly when they first
set up, and life is good from then on.


At 10/20/1999 13:41, Rick Macdonald wrote:
>On Wed, 20 Oct 1999, Glenn Kasten wrote:
>
> > We've just converted to Perforce, and some of our new users are making
> > the mistake of trying to use the same client on different computers.
> > Unless the root directory is a share or NFS mount, this will confuse
> > the p4 server.
> >
> > I would like to suggest that a new field be added to the client form,
> > which is the computer name. By default it would be the name of the
> > computer the client was created on. Users could change it to be a list
> > of computers, or any computer if they know it is safe. This would
> > prevent users from accidentally using a client on the wrong machine.
>
>...by default it should allow any host, as it does now!
>
>I wouldn't want this. We simply put the hostname in the client name.
>
>I find it handy to switch to various clients and see what they're sync'd
>to, run preview syncs to see what is out-of-date, etc, from any machine or
>even from home while dialed up to the office.
>
>...RickM...
>
>
>_______________________________________________
>perforce-user mailing list - perforce-***@perforce.com
>http://maillist.perforce.com/mailman/listinfo/perforce-user

__________________________________________________________________________
Eric Scouten <***@scouten.com> Software engineer @ Adobe Systems
THIS MONTH on www.scouten.com (Aug '99): Landscape & nature photography

* Lightning! (2 slides)
* Garden tour (29 slides)
* Four desktop images
__________________________________________________________________________

I find myself up my stream of consciousness without a paddle.
-Kevin Kling

[Bruce Edge]

I got around this problem with a rather convoluted use of nfs
mount points and links such that the client looks the same
from both machines.

For example:

Actual files are on //apple:/home/me/proj
NFS mount on orange: mount //apple:/home/me /mnt/apple/home/me
On apple: mkdir /mnt/apple/home
ln -s /home/me/proj /mnt/apple/me/proj

So, on both machines /mnt/home/me/proj is the same set of files.
Also, both machines are NTP time sync'd which may or may not be necessary.


Glenn Kasten wrote:
>
>
> We've just converted to Perforce, and some of our new users are making the
> mistake of trying to use the same client on different computers. Unless the root
> directory is a share or NFS mount, this will confuse the p4 server.
>
> I would like to suggest that a new field be added to the client form, which is
> the computer name. By default it would be the name of the computer the client
> was created on. Users could change it to be a list of computers, or any computer
> if they know it is safe. This would prevent users from accidentally using a
> client on the wrong machine.
>
> Glenn
>
> _______________________________________________
> perforce-user mailing list - perforce-***@perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user

--
Bruce Edge ***@sattel.com
Sattel Global Networks 818.709.6201 x122

[Nick Barnes]

At 1999-10-20 18:48:05+0000, Bruce Edge writes:

> I got around this problem with a rather convoluted use of nfs
> mount points and links such that the client looks the same
> from both machines.

I have also used NFS mounts to solve this problem, except that the NFS
server is not a development machine -- it doesn't even need developer
logins -- and so the mount points of filesystems on the NFS server is
irrelevant. In medium-to-large organizations I strongly recommend
locking developers out of critical servers.

The key is that the mount point of any filesystem which contains any
part of a p4 client view should be the same on any machine on which
that p4 client is run. This isn't hard to arrange, and is of
considerable benefit for reasons unconnected to Perforce.

Once you have arranged that, Bob can write his code on any machine
which has the particular version of the particular editor which he
prefers, and compile it on a machine which fits particular customer
requirements, and use p4 and NFS interchangeably on the two machines:
"p4 edit" on his edit box, "p4 submit" on his compile box, or
whatever.

> Also, both machines are NTP time sync'd which may or may not be necessary.

Time synchronization (within a second) is a good idea to get NFS to
play nicely. It's not necessary for p4; p4 does not use client time
for anything AFAIK. There are a variety of ways to get time
synchronization; I recommend NTP but some systems don't like it.

Nick B

[Stephen Vance]

I, too, would like to see the ability to tie a client to a machine, and have
requested this from Perforce. I agree that in the Unix world, NFS mounting to
create a homogenous user environment is a good idea for more reasons than just
Perforce clients. The comparable mechanism in the Windows world is drive
mappings.

However, these in themselves do not address issues of a heterogenous platform
environment. NFS for Windows and samba for Unix can help, but the basic
filesystem addressing syntax is different. And this doesn't even take into
account the Mac and others.

People make mistakes, and beginners make even more mistakes. I have run into
this as a fairly frequent beginner mistake, despite specific coaching to the
contrary.

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 to
Perforce's best practice recommendations. I have only found one situation in
which this is not a good recommendation, and that is portability builds of a
tentative fix for which exposure by submission is not appropriate (shared
branch, no branch, etc.).

Nick Barnes wrote:

> At 1999-10-20 18:48:05+0000, Bruce Edge writes:
>
> > I got around this problem with a rather convoluted use of nfs
> > mount points and links such that the client looks the same
> > from both machines.
>
> I have also used NFS mounts to solve this problem, except that the NFS
> server is not a development machine -- it doesn't even need developer
> logins -- and so the mount points of filesystems on the NFS server is
> irrelevant. In medium-to-large organizations I strongly recommend
> locking developers out of critical servers.
>
> The key is that the mount point of any filesystem which contains any
> part of a p4 client view should be the same on any machine on which
> that p4 client is run. This isn't hard to arrange, and is of
> considerable benefit for reasons unconnected to Perforce.
>
> Once you have arranged that, Bob can write his code on any machine
> which has the particular version of the particular editor which he
> prefers, and compile it on a machine which fits particular customer
> requirements, and use p4 and NFS interchangeably on the two machines:
> "p4 edit" on his edit box, "p4 submit" on his compile box, or
> whatever.
>
> > Also, both machines are NTP time sync'd which may or may not be necessary.
>
> Time synchronization (within a second) is a good idea to get NFS to
> play nicely. It's not necessary for p4; p4 does not use client time
> for anything AFAIK. There are a variety of ways to get time
> synchronization; I recommend NTP but some systems don't like it.
>
> Nick B
>
> _______________________________________________
> perforce-user mailing list - perforce-***@perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user

--
=======================================================================
Stephen Vance |
mailto:***@vance.com | http://www.vance.com
=======================================================================

A computer programmer is a machine for turning coffee into programs.
-- Paraphrase of the late mathematician Paul Erdo"s

[Greg Spencer]

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).

-Greg.

----- Original Message -----
From: Stephen Vance <***@vance.com>
To: <perforce-***@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
have
> requested this from Perforce. I agree that in the Unix world, NFS
mounting to
> create a homogenous user environment is a good idea for more reasons than
just
> Perforce clients. The comparable mechanism in the Windows world is drive
> mappings.
>
> However, these in themselves do not address issues of a heterogenous
platform
> environment. NFS for Windows and samba for Unix can help, but the basic
> filesystem addressing syntax is different. And this doesn't even take
into
> account the Mac and others.
>
> People make mistakes, and beginners make even more mistakes. I have run
into
> this as a fairly frequent beginner mistake, despite specific coaching to
the
> contrary.
>
> 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
to
> Perforce's best practice recommendations. I have only found one situation
in
> which this is not a good recommendation, and that is portability builds of
a
> tentative fix for which exposure by submission is not appropriate (shared
> branch, no branch, etc.).

[Stephen Vance]

Greg Spencer wrote:

> 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).

If this is the only copy of the physical client storage, then it is really the
same client. This is a good use of multi-homed clients. You would also want
to change the "compress" attribute of the client depending on which location
you were working from. However, if the physical media being moved is the hard
drive on a laptop, the computer is the same and the connection is different and
nodelocking the client is correct.

> 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.

We are simply talking about a one machine to many client relationship, only
constraining the left-hand side of the clause. I agree and would scream to
high heaven if I couldn't have half a dozen clients running on a machine at any
given time.

> 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).

I would probably prefer it server switchable for the default with a per-client
override. I generally wouldn't control it per user.

--
=======================================================================
Stephen Vance |
mailto:***@vance.com | http://www.vance.com
=======================================================================

A computer programmer is a machine for turning coffee into programs.
-- Paraphrase of the late mathematician Paul Erdo"s

[Scott Blachowicz]

Stephen Vance <***@vance.com> wrote:

> I have only found one situation in which this is not a good recommendation,
> and that is portability builds of a tentative fix for which exposure by
> submission is not appropriate (shared branch, no branch, etc.).

I use it like this...I have 3 systems. On one system, I do release builds.
On another system I do debug builds (and debugging). The third system, I use
primarily for source browsing, editing (& email & PIM & WWW ...). I've got
things setup so that the same client "root" points to the same set of files on
all 3 systems. Then, I use the "P4CONFIG" file stuff to specify which client
I'm in.

So, I've got 3 perforce clients (one for each system) and I can run 'p4
edit', 'p4 sync', etc on any of the systems against any of my 3 p4
client source trees. It seems to work well for me. This is all in a
homogenous environment, so I don't have to worry about the
cross-platform differences in file systems and such.

***@seaslug.org

[Stephen Vance]

Scott --

If I understand what you are saying, you have three clients defined for three
machines, each sharing the same physical storage and having distinctly different
purpose. If this is the case, I would suggest changing the arrangement for the
following reasons. If I misunderstood and you are not sharing physical storage,
then just take the following as reasons not to start.

First, the technical reason. Sharing the same physical storage between three
different client mappings messes up your have lists, unless you exercise
disciplined and frequent use of 'p4 flush.'

Second, the procedural reason. Sharing build areas with different purposes,
especially with release builds, leaves your builds open to contamination. Once
again, this is contingent on your discipline and care in managing the areas, but
it leaves you open to, for example, creating a release build that contains files
checked out through another view. Such a release build would not be
reproducible. Even if your have list was messed up for the release client, you
can get into a similar circumstance. This is why the release procedures I've
developed for my current development group specify creating a new client for
build. We also create a new branch for the release so that any small fixes that
need to be applied (including updating the version number) don't accidentally
pull in other activity that has occurred on the mainline.

Steve

Scott Blachowicz wrote:

> Stephen Vance <***@vance.com> wrote:
>
> > I have only found one situation in which this is not a good recommendation,
> > and that is portability builds of a tentative fix for which exposure by
> > submission is not appropriate (shared branch, no branch, etc.).
>
> I use it like this...I have 3 systems. On one system, I do release builds.
> On another system I do debug builds (and debugging). The third system, I use
> primarily for source browsing, editing (& email & PIM & WWW ...). I've got
> things setup so that the same client "root" points to the same set of files on
> all 3 systems. Then, I use the "P4CONFIG" file stuff to specify which client
> I'm in.
>
> So, I've got 3 perforce clients (one for each system) and I can run 'p4
> edit', 'p4 sync', etc on any of the systems against any of my 3 p4
> client source trees. It seems to work well for me. This is all in a
> homogenous environment, so I don't have to worry about the
> cross-platform differences in file systems and such.
>
> ***@seaslug.org

--
=======================================================================
Stephen Vance |
mailto:***@vance.com | http://www.vance.com
=======================================================================

A computer programmer is a machine for turning coffee into programs.
-- Paraphrase of the late mathematician Paul Erdo"s

[Scott Blachowicz]

Stephen Vance <***@vance.com> wrote:

> Scott --
>
> If I understand what you are saying, you have three clients defined for
> three machines, each sharing the same physical storage and having distinctly
> different purpose. If this is the case, I would suggest changing the
> arrangement for the following reasons. If I misunderstood and you are not
> sharing physical storage, then just take the following as reasons not to
> start.

Nope, it's not the case...I was referring to 3 separate physical
storage area, each referred to by the same directory path from 3
separate machines. The same as using an NFS automounter type
arrangement on Unix, but this work is on Windoze NT.

On the "first" machine, I have this:

SUBST V: e:\Projects
NET USE W: \\TWO\Projects
NET USE X: \\THREE\Projects

then on the 2nd machine:

NET USE V: \\ONE\Projects
SUBST W: h:\Projects
NET USE W: \\THREE\Projects

etc. The p4 clients each use client root settings like "V:\". It
might be nice to use UNC names for the client root values, but I don't
think Perforce would be able to resolve things correctly. For
instance, if I do

cd H:\Projects\Common

on the 2nd machine, but my client root is set to "\\TWO\Projects",
it'll probably tell me that the files aren't in my client's root.

***@seaslug.org

[Rick Macdonald]

On Mon, 25 Oct 1999, Greg Spencer wrote:

> 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).

Yes, absolutely! Unlike the $LOG$ business, which would need to be
globally (depot) set.

In addtion to an ON/OFF setting, I'd suggest a "prompt" setting, at least
for the GUI environments. This would prevent errors, but many new users
would (I suggest) eventually discover that yes, they do want to access a
client from another machine now and then after all.

...RickM...

[Richard Geiger]

Stephen Vance <***@vance.com> wrote:

> I have only found one situation in which this is not a good recommendation,
> and that is portability builds of a tentative fix for which exposure by
> submission is not appropriate (shared branch, no branch, etc.).

Our environment: "farms" of fairly powerful shared Unix computer
servers (mainly space/Solaris, Alpha/OSF1m, and x86/Linux) where
builds happen (a "build" actually requires multiple platform
arhitectures, since by a build we generally mean verifying that all
varients we care about build properly), with a mechanism for dynamic
load balancing that chooses where parts of the the build will run.

NFS volumes cross mounted by all servers, so developers always see
their home directories (which contain their client workspaces), by the
same canonical path on all hosts.

In situations like this, the identity of the host that happens to be
running the p4 client is pretty irrelevant. You just log in to
whichever host you want/need to use, cd into your workspace, and have
at it.

[Jeff A. Bowles]

At 02:59 PM 10/25/99 -0700, Richard Geiger wrote:
>NFS volumes cross mounted by all servers, so developers always see
>their home directories (which contain their client workspaces), by the
>same canonical path on all hosts.
>
>In situations like this, the identity of the host that happens to be
>running the p4 client is pretty irrelevant. You just log in to
>whichever host you want/need to use, cd into your workspace, and have
>at it.

Although I hate "yes, I agree" postings, I have to admit to writing one.

This one.

I've done exactly Richard's configuration a couple of times (on a
predecessor of Perforce, actually) for the same reasons. There
often was a "preferred machine" to access the workspace from,
which was the machine that the files PHYSICALLY resided on,
but that was solely for performance reasons. (NFS was never
a great performer for write operations over the net. That's been
optimized on some disk-farm NFS servers, however.)

I've used the "masquerade as someone else's client to unlock
a file or the like" a few times, also. That makes me a bit uncomfortable,
however...

-Jeff Bowles
San Francisco

[Stephen Vance]

I believe that my "portability test build" statement and this scenario
are variants of the same underlying usage pattern. Anyone want to take
a stab at characterizing it more generally?

"Jeff A. Bowles" wrote:

> At 02:59 PM 10/25/99 -0700, Richard Geiger wrote:
> >NFS volumes cross mounted by all servers, so developers always see
> >their home directories (which contain their client workspaces), by
> the
> >same canonical path on all hosts.
> >
> >In situations like this, the identity of the host that happens to be
> >running the p4 client is pretty irrelevant. You just log in to
> >whichever host you want/need to use, cd into your workspace, and have
>
> >at it.
>
> Although I hate "yes, I agree" postings, I have to admit to writing
> one.
>
> This one.
>
> I've done exactly Richard's configuration a couple of times (on a
> predecessor of Perforce, actually) for the same reasons. There
> often was a "preferred machine" to access the workspace from,
> which was the machine that the files PHYSICALLY resided on,
> but that was solely for performance reasons. (NFS was never
> a great performer for write operations over the net. That's been
> optimized on some disk-farm NFS servers, however.)
>
> I've used the "masquerade as someone else's client to unlock
> a file or the like" a few times, also. That makes me a bit
> uncomfortable,
> however...
>
> -Jeff Bowles
> San Francisco

--
=======================================================================
Stephen Vance |
mailto:***@vance.com | http://www.vance.com
=======================================================================

A computer programmer is a machine for turning coffee into programs.
-- Paraphrase of the late mathematician Paul Erdo"s

[Richard Geiger]

Stephen Vance wrote:
> I believe that my "portability test build" statement and this scenario
> are variants of the same underlying usage pattern. Anyone want to take
> a stab at characterizing it more generally?

Ah, Stephan, I think you hit on the cogent general statement in the
next message you sent (or, at least, "next" in the order i saw it in:)

Stephen Vance also wrote, in another message:
> If this is the only copy of the physical client storage, then it is really the
> same client. This is a good use of multi-homed clients. You would also want

There you have it: the generality is: you want the same client to
always reference the same physical storage. The identity of the host
platform running the Perforce client is largely irrelevant.

(The tricky part is that the Perforce server has no good way of
discerning whether a given client Root: path on one host references
the same physical storage as it does on some other host. (That will
depend on, for example, whether NFS filesystems are mounted
consistently, and so on.)

OK, well, yeah, there's also an exception to this generality: In our
environment, it's quite easy for both Unix and NT clients to reference
the same physical storage, but we don't maintain NFS mounts and CIFS
shares such that there's a canonical path that's identical across both
realms; my home directory from CIFS (windows hosts) is

\\ecco\rmg\

while from NFS (unix hosts) its

/n/ecco/rmg/

So, to switch from using the same client from one realm to another
(windows <-> unix, for example), I'd have to edit the client Root:.
There are also problems having to do with differing default
end-of-line conventions between Unix and Windows Perforce clients.
FOr these reasons, I don't generally encourage using the same client
workspaces from both Windows and Unix hosts around here. (Though is
can be done, if one knows what one is doing).

[Stephen Vance]

Richard Geiger wrote:

> OK, well, yeah, there's also an exception to this generality: In our
> environment, it's quite easy for both Unix and NT clients to reference
> the same physical storage, but we don't maintain NFS mounts and CIFS
> shares such that there's a canonical path that's identical across both
> realms; my home directory from CIFS (windows hosts) is
>
> \\ecco\rmg\
>
> while from NFS (unix hosts) its
>
> /n/ecco/rmg/
>
> So, to switch from using the same client from one realm to another
> (windows <-> unix, for example), I'd have to edit the client Root:.
> There are also problems having to do with differing default
> end-of-line conventions between Unix and Windows Perforce clients.
> FOr these reasons, I don't generally encourage using the same client
> workspaces from both Windows and Unix hosts around here. (Though is
> can be done, if one knows what one is doing).

Another interesting exception of this nature occurs when trying to use the same
client from Cygwin as from normal NT access means.

--
=======================================================================
Stephen Vance |
mailto:***@vance.com | http://www.vance.com
=======================================================================

A computer programmer is a machine for turning coffee into programs.
-- Paraphrase of the late mathematician Paul Erdo"s