On Thu, Apr 10, 2008 at 6:10 PM, Ben Collins-Sussman
<sussman_at_red-bean.com> wrote:
> On Thu, Apr 10, 2008 at 3:43 PM, John Peacock
> <john.peacock_at_havurah-software.org> wrote:
> > Benjamin Smith-Mannschott wrote:
> >
> > > Yuck. At first blush, this seems to me a pretty unnatural way to work.
> > >
> >
> > Me too.
>
> I think hundreds of thousands of perforce users would disagree with
> you guys. ;-)
>
> I have to admit, when I first started using perforce a couple of years
> ago, it seemed strangely restrictive compared to cvs or svn. But now
> running 'p4 edit' doesn't seem any weirder to me than running 'svn
> add', 'svn rm', 'svn mv', or 'svn cp'. It's just one more case of
> telling the system what you're doing. And holy awesome, what an
> incredible speed boost you get in return!
I've used perforce since before it was called perforce.. (p3.com,
remember that? I've been using it for something like 11 or 12 years
now). I have a constant love-hate relationship with it. There are
many things that they got right, but.. by god, did they screw up in
some colossal ways. If the WC-NG conversation is going to include p4
comparisons in it, then I'd love to vent some steam about what they
got wrong (and right).
The single biggest hassle with perforce, is that they went much
further with metadata centralization than we're talking about here..
The client-side metadata is actually stored on the server. This is
fine for small groups, or even large groups where there's an
administrator with a big stick and the authority to use it (eg: in a
company). We tried this on freebsd.org and it just doesn't scale. We
have a huge tree, and our developers love to check things out, all
over the place. Before we knew it, the server database was sinking in
client side metadata. (It's looking like we're going to need to go to
32GB of ram on the server. svn on a similar sized tree seems to be
comfortable in 8GB)
Having to do a 'p4 edit' is something that you get used to. It's
really the least of the problems.
The other big problem is that the shell client is antiquated even by
1996's standards. It has *no* directory awareness. If you put stray
files in there, it can't tell you. There is no 'p4 status' command or
equivalent. All p4 can tell you, is what files you told the server
that you were editing. People who use p4 for non-trivial things end
up writing scripts that scan for stray files and so on.
IMHO, while having p4 tell you when a file is open for edit by another
user is kinda neat, it really isn't worth the cost. If your
development model is branch centric (like it is with p4 on
freebsd.org), it is very rare that another person will be also editing
a file at the same time (well, besides you, on another machine).
The horrific cost of storing metadata on the server, the
administrative overhead and the antiquated command line client are the
killer reasons why p4 was a non starter for consideration for
freebsd.org.
On the other hand, p4 got a few things very right. Some of which I'll
sorely miss.
* client views. Your working copy is 'mapped' into server space via a
flexible table. You can synthesize a checked out tree from bits
scattered all over the server repository.
* branch views. Branches are tables of 'copy here to there, then
here2 to there2, then here3 to there3, etc'. A "branch" in p4 speak
is a name for this src,dest copy list. The advantage of this is that
populating the branch is atomic. With svn you'd have to do multiple
copies, remember the change numbers, etc.
* integrated configuration for things like file type mappings.
Instead of lame things like putting mime mappings in ~/.svn/config,
the pathname to file type mappings are stored on the p4 server (p4
typemap). So instead of having to beat people over the head to
remember to set 'binary' or 'keywords' on some file type, you can just
set shared mime-like mappings on the server. (The client can, of
course, override this. but the server can set the defaults)
* pervasive merge tracking as a first class feature. (think merginfo,
except 12 years ago)
* sane revision numbering, both for global changes and file revs.
Files are numbered 1,2,3,... in the tree as well as global change set
numbers. 6+ digit file revision numbers suck. Our security officer
folks are having a fit about how to specify version numbers in
advisories.
* saner client-side 3-way merging when resolving conflicts. (see
footnote). svn can do this, but requires a trivial code change.
(this could easily be in the config file)
* server specified commit template text. Even CVS supports this.
I honestly expect that most of our serious devlopers on freebsd.org
will use svk or git-svn for local work, but the svn client is mostly
good enough. I've already discovered that we have to put together an
extensive set of hooks to enforce settings for mime types, binary,
eol, keywords, etc since we can't depend on the clients getting it
right by default. (And to deal with custom keywords.. sigh.)
On the 3-way merge stuff.. In perforce, the format is like this:
>>> original
orig
=== theirs
their version
--- yours
your version
<<<
In svn, by default, you don't get to see the original text (just like cvs):
<<<<<<< .mine
your version
=======
their version
>>>>>>> .r2
With a 1-line change, you can sort-of get the p4-like semantics:
<<<<<<< .mine
your version
||||||| .r1
orig
=======
their change
>>>>>>> .r2
libsvn_wc/merge.c, in the call for svn_diff_file_output_merge():
- FALSE, /* display original */
+ TRUE, /* display original */
-Peter
--
Peter Wemm - peter_at_wemm.org; peter_at_FreeBSD.org; peter_at_yahoo-inc.com
"All of this is for nothing if we don't go to the stars" - JMS/B5
"If Java had true garbage collection, most programs would delete
themselves upon execution." -- Robert Sewell
**WANTED TO BUY: Garmin Streetpilot 2650 or 2660. Not later model! **
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-04-11 04:56:00 CEST