[p4] How to work with many users using only one client workspace

[Robert Cowham]

A minor addition to Jeff's excellent advice below, is that I come across
situations where say a regular build is done on a shared machine (or shared
drive) by more than one person (or a rotating team of people).

In this case more than one person may use the client workspace, sync it and
build. HOWEVER, this sort of workspace should really be treated as
read-only - don't make changes in it (without being very careful). If you do
have multiple people making changes in a client workspace then you are not
allowing Perforce to help protect you from losing concurrent updates to the
same file.

You can often get around the need for having multiple people work on it by
setting up a special user account to perform the builds, and indeed make the
whole process automatic such that a build is done nightly, the results
checked and emailed to appropriate people (together with a thunderbolt
emailed directly to the person who broke the build, but that's another
story...).

Robert
  -----Original Message-----
  From: perforce-user-admin at perforce.com
[mailto:perforce-user-admin at perforce.com]On Behalf Of Jeff A. Bowles
  Sent: Friday, January 12, 2001 07:05
  To: Filippo Ignozza
  Cc: perforce-user at perforce.com
  Subject: Re: [p4] How to work with many users using only one client
workspace


  At 04:15 PM 1/12/2001 +0000, you wrote:

    Dear Sirs,
    we are trying to setting up a perforce environment where there is
    only a client workspace for more then one user....

          When I'm teaching the Perforce course, I say very specific things
about
          sharing workspaces.  What follows is mostly a technical set of
guidelines,
          but at the end is a suggestion about when sharing a workspace
might make
          sense and saying that "usually, it's not necessary."

          The rule-of-thumb that I recommend is this:
                  "if it's the same physical area on disk with the same
pathname
                  then you can consider it the same workspace. It doesn't
matter
                  if it's accessed by multiple machines or multiple users,
so long
                  as it's the same disk: serial number 129-123023--12A or
whatever.
                  Note that this disk should be mounted so that you can use
the
                  same pathname for the workspace root, e.g. M:\homer or
                  /usr/marge/workspace."

          Then I give examples:
                  "If you have a removable ZIP drive in your E:\ drive at
work, and
                  you have a removable ZIP drive in your E:\ drive at home,
and you
                  wanna carry the cartridge back and forth, it can be the
same workspace
                  and therefore, the same workspace name: lisa.work or
whatever.
                  Why? Because it's the same physical disk, on the same
platform
                  type (oops, should've mentioned that), in the same
pathname."

                  "If you have a removable ZIP drive in your E:\ drive at
work, and
                  you have a removable ZIP drive in your F:\ drive at home,
and you
                  wanna carry the cartridge back and forth,  you cannot do
it without
                  making at least one change: the pathname to the workspace
needs
                  to be the same on both machines. So you might want to use
the
                  OS mechanism to refer to the ZIP drive as Z:\ on both
machines: on
                  Windows/NT, that would use the command ``subst  Z:  E:\
'' on one
                  machine and ``subst  Z:  F:\  '' on the other."

                  "If you have a fixed disk, e.g. your C: drive, and you
wanna share it
                  between two computers, you'll probably have to refer to
your workspace
                  using some shared-drive-letter like Z: or M: using that
``subst'' trick,
                  to make it a shared workspace."

                  "If the workspace will be shared between Unix and NT
users, and you
                  want to use 'samba' or NFS to do it, stop. My advice is
don't do it.
                  (Otherwise, if the Unix user does a 'p4 sync' they'll pull
down files
                  with Unix end-of-line, and the NT users using that shared
disk will
                  see the wrong end-of-line and ... well ... it can be done,
but it's just
                  borrowing trouble. Use separate workspaces."

          I hasten to point out that recent Perforce releases include a
"Host:" field in
          the client specification for a workspace that defaults to the
machine you were
          on when you ran "p4 client".  (I think this was done because it
was too easy for
          me to masquerade as your client and run 'p4 sync' to pull things
onto my own
          C: drive, but updating your workspaces "p4 have" data.)  So if
you're sharing
          a workspace between computers, you might need to remove this
field.

          The rule: if it's the same platform, pathname, and physical disk,
then you can
          share the workspace.

          Note that this rule is a technical one, not a recommendation of a
procedure.
          For shared development, probably separate workspaces makes more
sense.
          But for the once-every-blue-moon patches that release 1.2 requires
(and you're
          developing release 7.0 now) it might make sense to share the 1.2
patch workspace.
          Your choice.

          -Jeff Bowles

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.perforce.com/pipermail/perforce-user/attachments/20010115/3b39dbab/attachment.html>