[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

efficient "svn log" usage?

From: Robert Kleemann <robertk_at_oz.net>
Date: 2004-07-03 21:36:24 CEST

Hi guys. Quickly I have to give you major kudos on svn. I'm finally
able to ditch all my cvs wrapper scripts that avoid all the
unintuitive command switches. It's also great to have renaming and
moving built into the system. While using cvs I had developed a built
in aversion to renaming and moving files (especially directories) and
it actually took some time using svn before that behavior went away.

Here's the problem:

For cvs I had the following wrapper scripts:

cvsdate file-arg
Runs "cvs log" on the specified file. Parses the log for the most
recent change date and returns that date.

cvsnewest file-list
Runs cvsdate for each file in the file list and returns the most
recent of all those dates.

I used these programs to generate a "latest source date". cvsnewest
would be passed a list of files that are significant to a particular
distribution target. This is often incorporated into the distribution
target help information so the user can see what the latests version
of sources the target was built with. Note: this is different than
the build timestamp wich is just whenever the build occured. I've
since upgraded these scripts to svn.

svnnewest is often handed hundreds of files which means it can take a
long time to run and use lots of network bandwidth.

My question is: is this the best way to solve this problem? If you
want to ask svn the question "What is the most recent modification
date in this large group of files?" is this the best way to do it?
Can I speed up this query without doing something unsafe?


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Jul 3 21:38:11 2004

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.