> 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 Perforce submission is near instant in this case. Let me iterate
this again... with the p4 integrate -v option and the subsequent p4
submit, there is no working copy data going across the network and the
branch happens entirely on the server.
I just branched 64 megs of data in Perforce through 935 files and 191
directories. The integrate was the cost of printing 935 files to stdout
(which was just a few seconds). The submit was the cost of printing 935
files to stdout (which was even faster). That being said, the Perforce
operation is technically as fast as the Subversion operation is supposed
to be (when the code is fixed).
> 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.)
The timings speak for themselves. Perforce's branching and Subversion's
branching (when it is fixed) are near identical in speed.
> > 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
But not before the mistake has already been made. How do you, for
example, perform a project reorganization without hitting the server?
I'm moving around, let's say, 20 files between different directories.
In order to do it the "right" way and maintain history, I need to use
'svn cp'. However, svn cp instantly commits the change to the
repository. I need to email my team and tell them I'm locking down the
repository for some amount of time to not only perform the proper
Subversion operations, but also to change makefiles and any number of
other project configuration parameters.
Since Perforce does the commit as a separate operation, I can move my
files freely, revert them when I make a mistake, take three days to do
the whole reorganization, test it thoroughly, and THEN hand it off to my
team in a single commit.
My point is merely this... most other Subversion commands have to be
committed. Why does SVN cp get to do an auto-commit?
Thanks,
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:13:43 2002