> Perforce stores files in RCS layout, and the metadata in db format.
In fact, the metadata is supposedly (according to the Perforce mailing
list) in Berkeley DB format with a proprietary schema/format...
> > > * Branching files is significantly faster than Subversion. This
> > > operation will happen far less frequently, though, but
> still takes a
> > > long, long time.
>
> I didn't look closely at the test, but are you sure this is
> correct? Perforce has a different way of branching than any
> other setup I have seen. Requires two steps, one to create
> the branch (which is just a description on the server) and
> the other is to sync/commit the branch. That took a
> considerable amount of time for me using perforce (basically
> a full checkout, then commit).
>
> As BenS points out, server-side branching (the only kind I
> will ever do) is a 2 second operation regardless of the size
> of the dataset being branched. Subversion clearly wins in this case.
I provided both a local and network branch test for Perforce. By adding
the -v option to the p4 integrate command line, it does the branch "on
the server." At best, they come close to tieing (which is fantastic).
One of the reasons I like the delayed approach is it fits in way better
with the atomic commits. For example... I'm preparing a new tree that
is a combination of three trees. In Perforce, I branch each tree where
I want it. I check the physical representation of it on my hard drive,
if I wish. Then I commit the change, and the branch is created in one
atomic transaction.
Before I commit, if I don't like the way I branched it, I just revert
the change. All is done locally until I submit. That includes the p4
integrate -v option. This is a much safer way, in my opinion, than the
instant update on the server implied above (but not tested by me, so I
could just be spouting a bunch of crap... ;) ).
Josh
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jun 1 14:35:16 2002