[p4] How to make a clientspec which syncs only to a given tag

[Weintraub, David]

> It's always tempting to mix your metaphors (or in this
> case your paradigms). In clearcase there's no mixing of
> the split functionality of clientspec from sync. It's all
> in the viewspec. In cvs there's no spec at all. You just
> checkout based on a tag which may either be a label or a
> branch. If it's a branch then you're allowed to extend the
> branch with a checkin. If it's not then you can't.

In both ClearCase and CVS, once I set up a "default" label or branch in
my "view", it doesn't get changed unless I take action to change it
while in Perforce, I might accidentally resync my client without
realizing that I am now looking at something else.

For example, in ClearCase, I set my view to "sync" to a label. If I want
to "sync" to a different label, I need to physically change my view.
There is no worry that I will forget and accidentally "sync" to the head
of the branch without realizing it.

The same with CVS. If I do a "cvs update" with no options, I am sync'd
to what I originally checked out. If I want to change that, I'd have to
use the "cvs update -r <rev>" option.

However, in Perforce, when I use the "p4 sync" command, I am sync'ing to
the head of the branch by default. For example, imagine I do this in
Perforce:

   $ p4 sync //... at FOO   #Sync'ing to label FOO
   $ [...]      #Doing some random work...
   $ p4 sync    #Whoops! I just lost what I had previously sync'd to.

In the above Perforce example, my habit of typing in "p4 sync" to sync
my view has made me lose the label I was sync'ing to. Now, I'm operating
at the head of the branch, and I might not even realize it.

What we might like to do instead prefer Perforce to behave something
like this:

   $ p4 sync   #According to my Perforce client, I'm sync'ing to label
FOO
   $ p4 sync "//...#head"    #I have to do this in order to sync with
the head of the branch

In the book, "The Design of Everyday Things" by Donald Norman, this is
called a forcing function. A forcing function causes you to take a
positive action if you want to do something out of the ordinary. For
example, in most communities, if you have a stairwell that leads to a
fire exit, and the stairs go down beyond the fire exit to a basement,
you must have a door or bar that must be pulled open to be able to
continue down stairs past the fire exit.

That way, the default behavior of running down one flight of stairs
after another to escape the encroaching flames doesn't make you run past
the fire exit, into the basement, and too a fiery doom. Instead, you
come to a barrier and are forced to stop. You'll then see the fire exit
and flee to safety.

Normally, this isn't too much of an issue in Perforce in your normal
work routine. The "forcing function" is there when you working off a
particular branch. If I want to work on a branch, I must define my
client to use a specific branch, and any sync is based upon that branch.
If I want to change branches, I have to either physically redefine my
Perforce client or use another Perforce client.

The "forcing function" is missing with labels, but it is rare that I
actually want to do work based solely on a label. More likely, I want to
sync to a label for a specific purpose, then continue with my normal
work based upon the head of the selected branch.

Where I do see this as a problem is with creating a branch. In both
ClearCase and CVS, if I want to branch upon a label, the default action
is using that label. However, Perforce is different:

    I create my branch spec:

        Branch: REL_1.0
        Description:
              Branching based upon label Rel_1.0
        View:
              //depot/Foo/MAIN/... //depot/Foo/REL_1.0/...

And now I actually create the branch:

    $ p4 integrate -b REL_1.0 -s //...

Whoops! I forgot to mention that I want to branch based upon the label
Rel_1.0! And, yes, I do this all the time which is why one of the
reasons I rarely use branch specs. What Perforce really needs is the
ability to define a branch spec like this:

        Branch: REL_1.0
        Description:
              Branching based upon label Rel_1.0
        View:
              //depot/Foo/MAIN/... at Rel_1.0 //depot/Foo/REL_1.0/...

Now, when I create the branch:

   $ p4 integrate -b REL_1.0 -s //...

My branch will be based upon the spec in my branch spec as the default
behavior. If I wanted something different, I have to force the change by
specifying the change in the "p4 integrate" command, or by changing my
branch spec.

-----Original Message-----
From: perforce-user-bounces at perforce.com
[mailto:perforce-user-bounces at perforce.com] On Behalf Of Steven W. Orr
Sent: Tuesday, August 22, 2006 8:28 AM
To: Stephen Vance
Cc: Perforce Users
Subject: Re: [p4] How to make a clientspec which syncs only to a given
tag

On Monday, Aug 21st 2006 at 12:43 -0700, quoth William Deegan:

=>On 8/21/06, Stephen Vance <steve at vance.com> wrote:
=>>
=>>  Sorry, Bill. There is no way to make a client spec that will always
sync to =>> the same revision specifications. That functionality is only
in the sync =>> command. The client spec only specifies the mapping
relationship between the =>> workspace and the repository, not the
actual revision selection.
=>
=>O.k. so thats something which can be done with CVS and Clearcase, but
not =>with perforce.
=>Bummer.

It's always tempting to mix your metaphors (or in this case your
paradigms). In clearcase there's no mixing of the split functionality of
clientspec from sync. It's all in the viewspec. In cvs there's no spec
at all. You just checkout based on a tag which may either be a label or
a branch. If it's a branch then you're allowed to extend the branch with
a checkin. If it's not then you can't. It's like that old phrase, "If my
grandmother had wheels, she'd be a bus."

--
Time flies like the wind. Fruit flies like a banana. Stranger things
have  .0.
happened but none stranger than this. Does your driver's license say
Organ ..0 Donor?Black holes are where God divided by zero. Listen to me!
We are all- 000 individuals! What if this weren't a hypothetical
question?
steveo at syslang.net
_______________________________________________
perforce-user mailing list  -  perforce-user at perforce.com
http://maillist.perforce.com/mailman/listinfo/perforce-user