On 27 Aug 2008, at 07:37, Joshua Juran wrote:
Perforce does not have branches.
The notion of a "branch" of development is implemented in different
ways by different SCM tools. For me, CVS' invisible branching scares
the hell out of me - it's too easy to get non-sticky stuff mixed with
sticky stuff and end up in fuckedland right before a release. I also
just find the whole CVS thing a lot harder to visualise than
perforce's plain mappings.
What perforce does is implement branches in a way you don't like
because you don't want to like it! I personally like it because the
branches are right there - it's difficult to accidentally do anything.
In Perforce branch specs are better than macros because they have a
creator (ie someone to ask) and (should have) documentation in them,
and usually it's faster to integrate longhand anyway rather than
trying to understand what the branch spec means before you take the
responsibility of using it to make a change.
Is
p4 integ ./personalbranch_containsnewfeature/... ./trunk/...
really more painful than
p4 integ -r -b makemybranch
?
For me the first shows my intention much more clearly, and this is the
one I'd use.
8<
8<
I repeat: Perforce does not have branches -- at all. What it has
is integration.
Its strength is its integration facilities. They make it really easy
to create and maintain branches.
What I hate the most is that everybody still uses Perforce
anyway[1], even though the deficiencies don't get addressed[2], even
when much better free alternatives exist, due I guess to inertia and
the cost of switching.
Cost of switching away from Perforce is more than 600 bucks a head? I
don't think so. The cost in risk is high though, I guess, so maybe
you're right - this is some form of inertia.
Perforce is the Windows of version control.
You mean it works fantastically and never falls over if your devs are
responsible mature engineers and don't fuck about with it? :)
Josh
[1] The perl 5 codebase has moved from Perforce to git. But
employers?
[2] How do you reverse a submitted change?
That you ask question 2 at all shows you have some emotional or
religious prejudice against perforce - this is such a FAQ.
A change is a change is a change. What you want to effect is a change
which reverts the crap one you just made. Hang on though - you made a
crap change?
I would be asking why you checked shit into my repository and got
yourself into a situation where you have to revert when perforce makes
it really easy to make a personal branch to check your proto code into
and work in until such time that you are confident enough in your
change that you want to commit it to the trunk or a controlled branch.
You *never* need to check code in to test it using perforce. You can
maintain a personal branch which is *exactly equal to* the head or
trunk (or whatever "branch" you like) plus ONLY your code changes, so
you can test it and make sure you like it before you make the commit
somewhere important. AND you only need to use a personal branch if
you're bothered about the intra-change revisions. If the change is
small then just make the change on the live target branch and right
before you commit, after you've resolved, you have on your machine
exactly that branch as it is in the repo, plus only your changes, for
you to build and test to your heart's content before committing.
Reverts sometimes have to happen because a junior coder did something
dumb or someone headbutted the keyboard or something but they are
*very* rare and something which your perforce admin can sort out for
you in a jiffy. If they're not rare then you should be thinking about
how you can use perforce to a better advantage.
I know it's poor form to swagger on about years of experience on this
list but I've personally migrated going on a couple of hundred of
engineers to perforce from VSS / CVS / SVN over the years and the
reasons they don't like it are largely that they don't understand the
concepts (through no fault of their own). Once these are explained to
them in a way they can understand then they all - without exception -
even the most fervent SCM haters - loved perforce, largely because of
its speed and easy of use. Sorry to sound so happy clappy but it's
true - usually the poor bastards who have perforce foisted on them
don't have enough support to get them to that point.
Cheers,
Neil.
PS . Perforce (the company) don't generally implement features like
revert-whole-changelist because in practise you should never get to
the point in normal usage where that's necessary. The perforce devs
seem to think that making core engine improvements over bloat-features
which are rarely used is the most profitable use of their efforts. I
agree with them.
