4

I have to checkout big projects with svn that take a while, so I'm just wondering if I set it to --quiet or (-q) so no messages are printed it would be quicker? Or does that have nothing to do with it?

G.Rassovsky
  • 650
  • 8
  • 21
  • 3
    Interesting set of answers. I think the best idea is to measure it for yourself since it likely is going to depend on your environment. On *nix you can use the `time` command and on Windows you can use Powershell's `Measure-Command` cmdlet. – Patrick Quirk Dec 17 '14 at 16:19

3 Answers3

2

Definitelly YES, using the standard output always will make slower any process. I've made dumps, loads, and of course checkouts and commits of 10-15GB of data recently, and always made it with -q, cause it reduces in a really high amount of time the process duration.

David Mic
  • 117
  • 9
2

Unless you're on a VT100 terminal running at BAUD 300 or a Teletype terminal, the --quiet option probably won't do much good. The terminal is probably displaying your files being checked out faster than they're being fetched from your server.

If you're using a version of Subversion older than 1.7 and you're on Windows, you may have issues with your anti-virus program scanning files as they're downloaded from Subversion. In older versions of Subversion, each file was downloaded twice: Once in your working directory, and once under the .svn directory as a base version you could use to do svn diff without bothering the server. Many Windows users complained about slow checkouts due to this issue. Updating to 1.7 or 1.8 will make Windows checkouts much faster.


You can try a sparse checkout where you only checkout the files you want. For example, we do release branching, and I find it easier to simply checkout the entire branch, then update only the projects I'm working on:

$ svn co --depth=immediates $RSVP/branches/5.2

This checks out the entire branch and all of the projects on that branch, but only the directories immediately under the branch. I get the project names, but I don't checkout anything under the projects. I now need to update my vibortz project:

$ svn up --set-depth=infinity 5.2/vibortz

Now, all the files in this one project are checked out. You could take this further.

$ svn up --set-depth=immediates 5.2/vibortz
A  docs
A  src
A  dependencies

I am not interested in the docs or dependencies, but I am interested in the buffer code in this project:

$ src up --set-depth=infinity 5.2/vibortz/src/buffer
A  src/buffer
A  ...

I have the entire project (Infact, the entire branch!) as a Subversion working directory, but I am only checkout out the files I'm actually interested. I can update additional directories as I see fit.

Most of the time, when I hear about a project taking so long to checkout, it's because compiled binaries are checked into the project (which is a no-no, but we won't get into here). You want to checkout the entire project, but you don't want the binaries. Again, sparse checkouts may work for you. Assuming BASH:

$ src co --depth=immediates $URL/trunk/vibortz
A  vibortz/binaries
A  vibortz/docs
A  vibortz/resources
A  vibortz/source

I just want resources and sources:

$ src up --set-depth=infinity vibortz/source vibortz/resources

If I want all the directories except binaries, I can do this:

$ shopt -s extglob    # Kornshell users don't have to do this...
$ cd vibortz
$ src up --depth=infinity !(binaries)

The !(binaries) excludes the directory binaries from my update. All directories except binaries will be updated and expanded.

David W.
  • 98,713
  • 36
  • 205
  • 318
1

It depends. If the bottleneck is retrieving files from the server, then it won't make any difference. But if you have a slow console, then the limiting factor might be how fast it can spew lines to the terminal.

For a typical case, it's unlikely to make a difference, but there are corner cases when it would (SSH to remote machine over a slow link, and checkout there, to a local repo with lots of tiny files).

chiastic-security
  • 19,689
  • 3
  • 33
  • 62