[nycbug-talk] svnup(1) - worthy of promotion to base?
Fabian Keil
freebsd-listen at fabiankeil.de
Mon Mar 11 11:31:11 EDT 2013
Isaac (.ike) Levy <ike at blackskyresearch.net> wrote:
> --
> My observations so far:
>
> svnup(1) speed "feel"
>
> Without opening up any cans of worms on SCM tools, I believe the 'git effect' creates some unrealistic expectations for the utility. (Git's impact is so huge on development, it's become so popular, it affects/warps perception of other tools.) git(1) has spectacular indexing/hashing, it's implementation is really thoughtful compared to svn(1). So, remote fetching of deltas, on massive codebases, is extremely fast.
But actually checking out the fetched deltas scales with
the repository size.
> svn(1) itself- (and svnup(1)), is not quite as slick in this area. To this end, svnup(1) *feels* surprisingly "slow" when fetching deltas. Yet, for what it's doing, (comparing every file), it's pretty darned fast.
Did you use git for base, ports or other projects with similar size?
I'm not claiming that git isn't faster than svnup (which I never used),
but a lot of people seem to only use git for small projects and expect
it to perform similar well with larger projects.
Once upon a time I did that too, but then I started using git for both
ports and base on my admittedly old laptop.
Until the ARC is warm some operations are depressingly slow because git
lstat()s every monitored file (and even when you know better you can't
trivially tell git not to). To give you an example:
fk at r500 /usr/ports $time git fetch
remote: Counting objects: 1433, done.
remote: Compressing objects: 100% (508/508), done.
remote: Total 1014 (delta 599), reused 906 (delta 502)
Receiving objects: 100% (1014/1014), 936.97 KiB | 168 KiB/s, done.
Resolving deltas: 100% (599/599), completed with 230 local objects.
From git://github.com/freebsd/freebsd-ports
a486bc5..e355038 master -> origin/master
10e61e6..c4e0181 svn_head -> origin/svn_head
real 0m48.982s
user 0m1.064s
sys 0m0.699s
fk at r500 /usr/ports $time git checkout master
Switched to branch 'master'
Your branch is behind 'origin/master' by 131 commits, and can be fast-forwarded.
(use "git pull" to update your local branch)
real 4m51.360s
user 0m2.090s
sys 0m8.008s
fk at r500 /usr/ports $time git rebase origin/master
First, rewinding head to replay your work on top of it...
Fast-forwarded master to origin/master.
real 6m0.862s
user 0m2.308s
sys 0m12.356s
Fast-forwarding 131 commits in 6 minutes probably isn't the
kind of spectacular you were referring to.
It's reasonable once the ARC is warm:
fk at r500 /usr/ports $time git pull
remote: Counting objects: 59, done.
remote: Compressing objects: 100% (17/17), done.
remote: Total 39 (delta 26), reused 35 (delta 22)
Unpacking objects: 100% (39/39), done.
From git://github.com/freebsd/freebsd-ports
e355038..dc0fb02 master -> origin/master
c4e0181..532d005 svn_head -> origin/svn_head
Updating e355038..dc0fb02
Fast-forward
databases/rubygem-familia/pkg-descr | 1 +
databases/rubygem-redis/Makefile | 2 +-
databases/rubygem-redis/distinfo | 4 ++--
devel/rubygem-stella/pkg-descr | 1 +
graphics/ruby-gdal/Makefile | 5 ++---
www/rubygem-em-websocket/Makefile | 2 +-
www/rubygem-em-websocket/distinfo | 4 ++--
www/wgetpaste/Makefile | 8 ++------
www/wgetpaste/distinfo | 4 ++--
9 files changed, 14 insertions(+), 17 deletions(-)
real 0m16.813s
user 0m1.823s
sys 0m3.183s
But then again, I reboot the laptop at least once a day
and the ARC isn't persistent (yet) ...
Fabian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://lists.nycbug.org/pipermail/talk/attachments/20130311/300fdaea/attachment.bin>
More information about the talk
mailing list