[p4] branchspec reversed or not?

[Dave Lewis]

  > > She would do "p4 integ -r -b v2.0-main" in order to handle this reversal.
  > > 
  > > So, now I'm confused. It seems as if she's introducing a new 
  > > "Better/Best Practices in Perforce" suggestion. She prefers the reversed 
  > > branchspecs, but doesn't really say why that I can see. I'd like to the 
  > > "best thing" going forward. It doesn't really matter so much in this 
  > > case, but can anyone suggestion what her motivation is here?
  > 
  > I wondered about this as well. The good idea that I got from this was
  > not the order itself but to at least name the branch spec to indicate
  > the source-target (left-right) codelines and order. For all these years
  > I've been giving mine names that only indicate the name of the feature,
  > so I'm always having to look at the spec to make sure I know which
  > direction it's written, not to mention what two codelines are specified.

There is definitely value in having a nomenclature with regards to 
client specs, labels, and  branch names.

We do something like

product   - stands for the main line

product-2.0  - the 2.0 branch, branched from main

The "-" sort of means branched from.

the template client spec would be

product.<platform>  like product.solaris, product.nt
or product.all, if one client spec would work on all platforms.

labels incorporate the client template name, such as
product-all-<releasenumber>-<status>

so product-2.0-all-2.0.1-qa4  would indicate a qa drop
for release 2.0.1, using client spec template product-2.0.all
That also tells you that its on  branch product-2.0, and not
on branch product-2.0-2.0.1   The hyphen notation gets a bit
tiresome when there are branches of branches of branches.

and the depot paths would look like

//depot/product/main/...
//depot/product/product-2.0/...

This makes the branch name identical to the 
branch directory name.

yeah, its a little redundant, and some things 
are a bit inconsistent...

Of course, naming is a *big* can of worms.  

dave