[p4] Workspace option: exclusive open

Sun Sep 16 10:39:52 PDT 2007

I think it comes down to this:

We trust our developers to work on multiple releases on their own
systems,

dividing them up as subdirectories. We don't require them to "hide"
directories

from themselves in, for example, Windows Explorer. They are free to move

from directory to directory at will, in the most convenient way
possible. This is

irrespective of  any version control or process.

Therefore, forcing Perforce to mask this reality seems counterproductive
and

prone to errors, as well as adding delays (and we chose Perforce mainly

because it did not introduce significant delays). It's counter to our
efforts to

map our depots and workspaces/development systems in a logically similar

manner, as well. (That is, the view I see in Explorer is pretty much
identical to

what I see in P4Win.)

In five years, I've never seen a file submitted to the wrong branch I
attribute

this in part to the 1:1 relationship between the depot and development 

environments and the ease with which developers can move files between

the two.

On the other hand, any shop that is seeing a problem attributable to a
single

workspace setup probably should try multiple workspaces to see if that
helps.

-Wm

________________________________

From: Stephen Vance [mailto:steve at vance.com] 
Sent: Friday, September 14, 2007 7:32 PM
To: Gabor Maghera
Cc: Ivey, William; perforce-user at perforce.com
Subject: Re: [p4] Workspace option: exclusive open

I agree with Gabor that one branch per workspace is a best practice.
Before I detail why and clarify what I see as possible misconceptions in
the thread, let me also say that this opinion is not universal within
Perforce or the consultant and trainer community as far as I can tell,
and I've had several explicit discussions on the topic. What seems to be
the common ground between whether it's a best practice or not is that
one branch per workspace is a safe approach for beginners and a not
inadvisable discipline for everyone, while there are certain perceived
conveniences for having multiple branches in a workspace.

First, here are the top reasons I prefer one branch per workspace, even
as a discipline for experiences users.

1.	A changelist is strictly associated with a workspace. As a
logical unit of work, a changelist should only apply to one branch if
your branches represent your process the way they should. If the "same
change" needs to be applied to multiple branches, it should be
propagated through integration and those integrations should be in a
different changelist from the original modification. One branch per
workspace prevents you from composing, accidentally or deliberately,
changelists that consist of modifications on multiple branches.
2.	To perform an integration, you *only* need to map the target of
the integration into your workspace. The source already exists on the
server and is read-only. Perforce knows where to get it. It doesn't need
to be on your local disk. Having your target branch as the only branch
in the workspace prevents several common errors that affect even
seasoned users. If you forget the '-r' option to integ with a branch
spec, you'll get an error rather than an undesired result on source that
could possibly be open for edit. If you make a mistake in your source
specification, you get an error rather than undesirable results.
3.	One branch per workspace reinforces the concept of a workspace
as exactly that, a place where you do some specified set of work. This
seems trivial, but it means that you encapsulate some set of related
tasks in their own area. It also means that if you have two sets of
tasks that affect the same source, you have the option to create a
workspace for each mapped in the same way, but with the different tasks
independent of one another.

Now for the clarifications:

*	Using P4CONFIG, you can switch workspaces by changing
directories as easily as you can change "branches" by changing
directories in a larger workspace.
*	Using GUI tools, changing the workspace in the drop-down or by
opening another window is an easy operation.
*	Since GUI tools have no concept of "current directory" it's even
easier to make the above-mentioned integration mistakes in a larger
workspace.
*	You don't need to "see" the source branch in order to integrate
from it (i.e. use it as the source of an integration).
*	The only additional overhead for a workspace is an additional
client spec and possibly an extra P4CONFIG file. If you were going to
sync from that tree anyway, there's no additional disk usage.

Anyway, that's my $0.02. Really, neither is right or wrong. One can be
safer, one can be more convenient depending on your work habits.

Steve

Gabor Maghera wrote: 

I think we are on the same page as far as workspace or client
definitions,
let's call it the client workspace as Perforce does, perhaps.

And you are correct, in order to integrate you do need a workspace which
encompasses the branch and the parent codeline.  Using dedicated
workspace
for each codeline is a best practice for doing development work in that
codeline other then integrating.  That's a recommendation to be given to
developers who do work sometimes "here" and sometimes "there" as far as
codelines go.

Have a good weekend all,
Gabor

On 9/14/07, Ivey, William <william_ivey at bmc.com>
<mailto:william_ivey at bmc.com>  wrote:

	If you're workspace can only see one branch, how do you
integrate

	between release branches? (I can't see this being a best
practice if

	it doesn't work - and, by the way, I got the idea from
Perforce's own

	documentation.)

	If I have two workspaces and change directories, but forget to
change

	workspaces (and P4CONFIG doesn't work with the GUI) then I might

	not submit a file into the wrong branch - but I will create a
useless

	change on the wrong branch, and fail to update the branch I
intended.

	Whereas if I have one workspace that maps multiple server
branches

	to multiple directories on my system, changing directories is
all I need

	to do and everything will go as intended. Perforce automatically
directs

	the command to the right branch based on my local directory path
no

	matter what client I happen to use. That's part of its design
and I
	don't

	see any easy way to create the problem you describe by doing it
this

	way.

	I think you are misinterpreting the term "workspace" (replace it
with

	"client" and maybe my meaning will be clearer). I'm certainly
not

	talking about mixing file from multiple branches in a single
directory

	on my system.

	-Wm

	________________________________

	From: Gabor Maghera [mailto:gmaghera at gmail.com]
	Sent: Friday, September 14, 2007 3:35 PM
	To: Ivey, William
	Cc: Rick Macdonald; perforce-user at perforce.com
	Subject: Re: [p4] Workspace option: exclusive open

	It may not be as efficient to set up a dedicated workspace for
each
	codeline, but it is a safety guard and a best practice.  This is
	especially important for release codelines but it also helps
with
	development codelines.  The idea is to reduce the likelihood of
someone
	checking code into an inappropriate branch and therefore
destabilizing
	it.

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

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

-- 
Stephen Vance
www.vance.com