StatSVN › StatSVN Users

Fwd: old issue, revisited.

2 messages

Jean-Philippe Daigle-2

Fwd: old issue, revisited.

Reply Threaded

Posting to statsvn-users for Larry Lavigne (who's having trouble posting).

Larry, reading your error message, my first guess was "ok, v1.4.4 is in his PATH, but he checked out his working copy with v1.5".

After reading the steps you've taken to debug the issue, it seems this is not the case, as the 'which svn' and 'svn --version' commands are pointing to 1.4.4 AND you've tried a manual checkout using this version. I'm kind of at a loss trying to think of an explanation, but if I were you,

1) I'd first confirm one last time that I could do a random diff operation on a checked-out file manually:

"svn diff -r WHATEVER:HEAD some_checked_out_file.c" and make sure it doesn't give you the "too old" error. The fact that you were able to get a logfile using command-line svn is evidence this should work too.

2) With this confirmed, I'd dive into deeper debugging: I see you're running on Windows, so I'd start up ProcMon (http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx), launch StatSVN on that directory and logfile again, and capture the output. Do this fast and on an idle system because ProcMon will collect A LOT of data. Stop capturing immediately after you get the error, and analyze the ProcMon log, looking for the spot where java.exe does a windows CreateProcess call. You should be able to see the svn.exe executable being launched, its path, and see its status when it dies. This might give you excellent clues.

---------- Forwarded message ----------
From: Lavigne, Larry <[hidden email]>
Date: Mon, Nov 3, 2008 at 3:57 PM
Subject: old issue, revisited.
To: [hidden email]

I am having trouble posting this (need to get my account straightened out),

could you post this for me along with any directions in the help forum.

thanks.

Please note:

I'm trapped at SVN V1.4.4 and updating further at this time is not an option.

Also this was all working until a recent upgrade of the Repository from SVN V1.1 to V1.4.4.

Developers are using a mix of tortoisesvn V1.4.4 and V1.5.2.

I'm using V1.4.4 to match the repository.

Nothing else in the working environment has changed.

My basic working environment is listed below.

ANY suggestions for debugging or correcting this situation would be welcomed.

COMMANDLINE (all on one line):

/cygdrive/c/SVNHOME/tribe/9.0.0.0$ java -jar statsvn.jar

-output-dir C:/SVNHOME/tribe/9.0.0.0/stats

C:/SVNHOME/tribe/9.0.0.0/svn.log

C:/SVNHOME/tribe/9.0.0.0

OUTPUT:

Oct 1, 2008 7:48:21 PM net.sf.statsvn.util.JavaUtilTaskLogger info

INFO: StatSVN - SVN statistics generation

Oct 1, 2008 7:48:21 PM net.sf.statsvn.util.JavaUtilTaskLogger info

INFO: svn: This client is too old to work with working copy '.'; please get a newer Subversion client

Oct 1, 2008 7:48:21 PM net.sf.statsvn.util.JavaUtilTaskLogger error

SEVERE: Repository root not available - verify that the project was checked out with svn version 1.3.0 or above.

SUBVERSION:

/cygdrive/c/SVNHOME/tribe/9.0.0.0$ which svn

/cygdrive/c/Program Files/Subversion/bin/svn

/cygdrive/c/SVNHOME/tribe/9.0.0.0$ svn –version

/cygdrive/c$ svn --version

svn, version 1.4.4 (r25188)

compiled Jun 8 2007, 18:49:42

Subversion is open source software, see http://subversion.tigris.org/

This product includes software developed by CollabNet (http://www.Collab.Net/).

The following repository access (RA) modules are available:

* ra_dav : Module for accessing a repository via WebDAV (DeltaV) protocol.

- handles 'http' scheme

- handles 'https' scheme

* ra_svn : Module for accessing a repository using the svn network protocol.

- handles 'svn' scheme

* ra_local : Module for accessing a repository on local disk.

- handles 'file' scheme

TORTOISESVN:

TortoiseSVN 1.4.4, Build 9706 - 32 Bit , 2007/06/09 09:44:02

Subversion 1.4.4,

apr 0.9.12

apr-iconv 0.9.7

apr-utils 0.9.12

berkeley db 4.4.20

neon 0.26.3

OpenSSL 0.9.8d 28 Sep 2006

zlib 1.2.3

WORKSPACE:

Windows XP SP2, 2GHz, 2GB RAM

BASH_VERSION='3.2.39(20)-release' (cygwin)

JAVA_HOME=/usr/java/jdk1.6.0_07

LANG=en_US

TortoiseSVN 1.4.4 was used to check out the local workspace.

/cygdrive/c/SVNHOME/tribe/9.0.0.0/.svn$ cat format

A manual checkout resulted in the same information and result.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Statsvn-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/statsvn-users

Jean-Philippe Daigle-2

Re: old issue, revisited.

Reply Threaded

On Tue, Nov 4, 2008 at 5:00 PM, Lavigne, Larry <[hidden email]> wrote:

SUCCESS.

Followed your advice (it was great).

Number 1 worked just fine.

Number 2 however showed some surprises!

PATH='/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/cygdrive/c/Perl/site/bin:/cygdrive/c/Perl/bin:

/cygdrive/c/Program Files/Subversion/bin:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:

/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/ant/bin

Note the "order" of the path above,

/cygdrive/c/Program Files/Subversion/bin (v1.4.4) comes BEFORE the entry

/cygdrive/c/WINDOWS/system32.

When I started this upgrade process I was careful to search the entire disk for instances of svn.exe

and to destroy any (about a half dozen) that were not in the /cygdrive/c/Program Files/Subversion/bin path.

I also deleted all C:\WINDOWS\Prefetch entries of svn.exe.

Then !

From the command line I ran svn –version and got v1.4.4, good.

From the script the same command gave v1.4.4, good, but the java command still failed.

BUT!

after running the java statsvn command line while running procman, the procmon showed the following entries :

2:12:06.6117124 PM      svn.exe 524       Process Start                SUCCESS        Parent PID: 3432

2:12:06.6117135 PM      svn.exe 524       Thread Create                SUCCESS        Thread ID: 2728

AND !

2:12:06.6118113 PM      svn.exe 524       QueryNameInformationFile C:\WINDOWS\system32\svn.exe (v1.3.1)

SUCCESS        Name: \WINDOWS\system32\svn.exe

Very bad. This had been erased before and also appears after Subversion/bin in the given PATH.

I still don't know why the system32 svn.exe is being found before the Subversion svn.exe.

OUTSTANDING QUESTION :

the cmdline and script are both finding the correct exe using the PATH, but statsvn.jar is not.

Is statsvn using an internally defined/altered PATH ?

LESSONS LEARNED :

1) when you search using windows, use the advanced search options and check the box for "look in hidden files and folders".

2) make sure you've dealt with "windows xp's system restore" else if you delete a file from a system directory, it'll be automatically restored.

3) if you can't solve a problem in a couple hours, seek serious expert advice. The only stupid question is the one not asked.

Thanks so much for your help and the tool!

Hi Larry,

Glad to hear you had some success.

1) I wouldn't worry too much about the WINDOWS/Prefetch directory, I don't believe it'll actually execute anything from there (unless it's a perfect match for the real target ? (AFAIK)).

2) I have NO IDEA how you ended up with a copy of svn.exe in WINDOWS/system32 but that's quite funny :)

3) No, statsvn doesn't have any kind of hardcoded or weird path resolution to find the svn executable, it just relies on a "Runtime.exec()" call in java, so whatever executable is loaded depends on what the Java VM decides is the first on the path when it runs the exec() call. I'd be curious to know where your java executable was - if it was also in system32 it might have looked there first?

Cheers!