[p4] Re: sharing clients

[Viktor Haag]

Dennis Wheeler writes:

 > Both users have mapped the same UNC path to the internal
 > website to an identical local drive letter on each of their
 > own machines. (will Perforce work directly with a UNC path?).

Rats. Not as far as I can tell.

 > One problem you will have, is that when one user checks out a
 > file for edit and saves their changes, the changes are now
 > _live_ on the webserver, ** even before the submit **!

Exactly. That's why you structure your workspace in such a way as
to account for that fact.

Our docs workspace is devided, essentially, into 'dev', 'test',
and 'prod'. All the work on the docs goes on in the 'dev' area,
where the "main trunks" of document revisions are kept. When we
do a 'pdf' build of a doc, it gets put over into the 'test' area
(by hand, actually), and these PDFs also get versioned (for
various reasons I won't go into).

When we want to cut a release, we apply a label to all the source
files that create a PDF, and the PDF that was built with those
versions. Then we can use that label to safely recreate any
release cut, and we can use that label to branch the appropriate
source and built docs to other areas of the company for their use
(like QA for testing).

We have a local web server that is set up to point to our 'test'
and 'prod' areas so that people inside the comany can easily get
to copies of the documents worked on by our group. And of course,
our test and prod areas are shared through Samba and NFS, so
people can get read access to them through the local network as
well.

 > My users now have a complete misunderstanding of why they even
 > need to submit changes. They don't understand revisions and
 > revision history, or how to revert changes. And for them,
 > removing files from client is the same as deleting the files.

In my experience, maintaining a common workspace is a different
way of working with version control from the 'sandbox'
method. When the concept of 'sandboxes' first came along, those
used to working in a common workspace were also mightily
confused.

What's required is education and training of the appropriate sort
-- i.e. don't get someone in to teach people how to use the
version control system along 'sandbox' lines if they're going to
be working in a common workspace environment.

 > Fortunately, this is only a test webserver, but I was hoping
 > they they would learn from their mistakes enough to let me
 > help them setup their systems the "right" way.
 
Heh. "Right" indeed. In my opinion, it's just a different work
methodology, that's all.

 > My recommendation -- don't let your users do this, not even as
 > a temporary measure! Use the daemon to update your remote
 > server directly from Perforce, and let your users only work on
 > files on their on machines. You can setup local Personal
 > webservers so that they can test their work.

And then who gets to maintain all those Personal webservers? And
suddenly every single provider of content has (potentially) to
worry about builds of other "code" parts of the webserver for
which they're not really capable, etc, etc.

For every problem you can point out in the common workspace
methodology, one can come up with a problem that the sandbox
methodology causes.

However, I will admit that often the benefits provided by sandbox
ways of working are greater than the cons, for people who more
closely follow 'software developer' modes of work.

-- 
Viktor Haag                           Senior Technical Writer, RIM
'79 99, '89 9000T, '00 9-3 SE         My opinions are my own, only.
tc++ ru ge(+) !3i c jt- au(-) pi+ he(+)