[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