svnversion is pretty slow, particularly on windows

[exarkun]

buildbot uses the svnversion program to pick a version number to report. svnversion takes a while to run though. On windows, it often takes several minutes, which can be longer than the actual build takes. Apparently svnversion is used to provide a consistent version number, regardless of whether "svn update" or "svn checkout" is being used, since they report different version numbers.

I suggest using "svn info" instead of "svnversion" to get a consistent version number.

[dustin]

Why does svnversion take so much longer? That's very strange. If 'svn info' is that much faster, perhaps there's something we're doing wrong?

[igor]

Replying to dustin:

Why does svnversion take so much longer?

svn info is much faster because it performs a very different operation than svnversion. All it does is reads the contents of .svn/entries file *in the directory it's run from* and reports the version recorded there.

Now, if you have a complex source tree, svn allows you to check out different versions of the subtrees. E.g., one can check out r10000 of server/src, r12000 of server/src/core and r11000 of server/src/cli.

If you run svn info in server/src, it'll just say that you've got r10000 and it'll take no time whatsoever.

On the other hand, svnversion will actually go into subdirectories *recursively* to check their versions too. So in this case it will report something like r10000:12000. Moreover, it will notice if you have any local modifications in your working tree; if you do, it'll add "M" to the version number.

Depending on how your build process is set up, knowing the difference may be quite important, imho, so I think it's better to make the use of svn info vs. svnversion configurable rather than just replace one with the other.

[dustin]

Interesting! I don't necessarily see a use-case for the svnversion output being useful, so I think that svn info should probably be the default, but I don't see any reason not to make this configurable.

[dustin]

Once #669 is cleaned up, this should be easier.