[p4] Perforce vs VSS (again)

[Stephen Ng]

Hi Jeff (did you do some consulting work for ProfitLogic?),

A quick note:  *I* don't need to be sold (I've used Perforce for many
years, at a couple of different jobs), I need to sell other engineers
and managers.

> In VSS, at least the last time I used it, you couldn't easily 
> create a branch, make changes in the parent, and propagate 
> those changes to the branch, repeating as often as you 
> wanted. (It looked like a branch was a one-way trip.)

When was the last time you used it?  I personally used VSS about 5 years
ago, but in order for me to have a compelling argument (for that matter,
in order for me to make the right decision for the company), I need to
compare today's Perforce with today's VSS.

I found this quote on a mailing list (comparing VSS with CVS)

"VSS has a merge feature to synchronize files that have been branched
(cloned).
It automatically keeps track of what has been already merged, so you can
bring
each independent version up to date with all the others. "

This sounds a lot like Perforce merging, but I don't know if this is
true or not (and the documentation isn't very helpful).

> 
> Moreover, you couldn't easily make a branch based on
> revisions from the past, only the current revision. (I think 
> that's a VSS design goal, since it constantly loses revisions 
> from the past it can't find them to use as a starting point 
> for a branch.)
 
Branching based on an old revision is a nice feature, but how important
is this, really?  Most of the time you make the branch at the time of
release, not after.

Interestingly, the organization here has been using VSS for over two
years now, and VSS data loss has *not* been a complaint.  Either we have
been lucky, or, possibly, Microsoft has cleaned up their act here (they
did change the file format for 6.0).

> In Perforce, also, a branched file is often a lazy
> copy on the server, which means that it updates
> database entries but doesn't actually copy content
> for the new branched file because the copy would
> be redundant, take up space, and unnecessarily lose time.

Good point, a branch is faster under P4.  This is nice too, but one
could argue that branching doesn't happen that often.
 
> Also, it's pretty easy to choose to leave a bug fix
> entirely in the branch because it was a nasty hack that
> you don't want included in the parent codeline. Even if
> later changes to the same file in the same branch are
> to be included in the parent, that particular modification 
> can stay in the branch.
> 

Nice, but not *that* common.

One reality of our situation is that in order to justify the cost of
switching, Perforce doesn't just have to be better, it has to be
*substantially* better.  (Now I believe that changelists alone are
enough of an improvement to justify this, but I'm wondering about
branching in this case).

--Steve