> From: Joshua Jensen [mailto:jjensen@workspacewhiz.com]
>
> > 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).
>
In order to fully mirror what svn cp lets you do, you need to also time
the cost of the appropriate Perforce commit operation.
i.e. does the following Perforce command sequence work:
p4 integrate -v <src> <target>
p4 commit
The Subversion folks are guessing that even if it does work without
requiring an intervening "p4 sync" that the time frame to complete both
of those operations is O(N) as opposed to O(1). Regardless of whether or
not Perforce's constant factor is much smaller given how it knows your
clients current state.
> 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.
>
Even if "svn copy" were delayed until a commit, it still should be
substantially faster than Perforce. (If we've understood Perforce's
storage model correctly.)
> 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... ;) ).
>
SVN also lets you instantly fix the problem as well:
svn delete <target>
svn commit
Bill
---------------------------------------------------------------------
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:36:11 2002