[p4] branchspec reversed or not?
dlewis at vignette.com
Wed Dec 21 08:44:34 PST 2005
> > 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
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
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.
More information about the perforce-user