expected fs format between '1' and '3' found format '4'

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Our server was upgraded to 1.6.3
2. Making a connection via svn+ssh://
3. I get the above error

What is the expected output? What do you see instead?
I expect to see my repository,   I get an error and do not see my data

What version of the product are you using? On what operating system?
v1.1 (1.1b3)

Please provide any additional information below.

Original issue reported on code.google.com by cpesarch...@gmail.com on 11 Jul 2009 at 3:17

[GoogleCodeExporter]

What version of Subversion are you running on your machine?
[What does it show in the svnX Preferences window?]
Is 'Call Subversion libraries directly' on or off?

However, older svn clients should be compatible with newer servers so it may 
not matter what version you use.
If your server is another machine then I don't see how accessing your 
repository via svn+ssh could cause
this error because of svnX or what version of the svn client you are running.

I believe that that error message means you are trying to access the repository 
with an
older version of svnserve/svnlook than the version for which it was created.
In other words I think your server is set up incorrectly.

Was this working correctly before you upgraded the server?
If you ssh to the server & then type `svnserve --version` what does it report?
Alternatively, if you type `svn info svn+ssh://<path-to-your-repo>` into a 
Terminal window
do you see a similar error?

Original comment by chris...@gmail.com on 12 Jul 2009 at 2:26

[GoogleCodeExporter]

There's been no response.
I've seen no confirmation of this problem.
I don't believe this is an svnX issue.
I'm marking this issue as invalid.

Original comment by chris...@gmail.com on 22 Jul 2009 at 3:56

• Changed state: Invalid

[GoogleCodeExporter]

I just updated to the new version of svnX, and I have run into a problem quite 
similar to this. Whenever I attempt to update using svn+ssh://, I get the error 
message: 
"svn: Expected FS format '2'; found format '3'"

Further, if I use the review feature to commit changes to the repository, I 
recieve this added information:
svn: warning: The depth of this commit is 'empty', but copied directories will 
regardless be committed with depth 'infinity'. You must remove unwanted 
children of those directories in a separate commit.

I have updated to svn version 1.6.13, and I am using the same version number 
for svnserve (these versions are identical for both server and client).

Note that I CAN update and commit changes when running svnX on the server 
computer directly (i.e. when not using svn+ssh) though I still get the svn 
warning about directory depths... but everything works. I would greatly 
appreciate any help! Thanks.

Original comment by wolf.aar...@gmail.com on 4 Nov 2010 at 6:55

[GoogleCodeExporter]

You can safely ignore the warning.  [See issue 120 Comment 9.]

The "svn: Expected FS format '2'; found format '3'" means that the Subversion 
file-system format is not supported by the version of Subversion that was run.  
Which probably means that it ran /usr/bin/svn (on the server), which is 
probably not 1.6.13.
I think you need to add /opt/subversion/bin (or where ever your 1.6.13 is) to 
the beginning of the PATH env for the user on the server that is running the 
Subversion server.

Original comment by chris...@gmail.com on 4 Nov 2010 at 8:15

[GoogleCodeExporter]

So I checked the version of svnserve being used on the server (over ssh) and it 
is indeed 1.6.13. Also, I have checked my PATH and the very first element of my 
PATH is /opt/subversion/bin, where the version of 1.6.13 is located. Also, svnX 
is set to look for svn in /opt/subversion/bin inside the preferences window.

All of these settings and versions are identical on the server (a desktop of 
mine) and the client (my laptop). The desktop can access the repository using 
the file:// connection method, but my laptop cannot access it using the 
svn+ssh:// method (Note that I am using ssh keys, in case this matters.) This 
repository was created a year ago and maintained using svnX version 1.0 (and 
also I think svn 1.6.x). I decided to finally upgrade today, but now I am 
having these problems. Thank you so much. I really appreciate your fast 
response.

Original comment by wolf.aar...@gmail.com on 4 Nov 2010 at 8:37

[GoogleCodeExporter]

I would be willing to put money (if I had any) on the theory that ssh is 
launching /usr/bin/svn* NOT /opt/* on the server.
It's NOT your PATH it's the PATH that ssh will see/use.  It's probably 
controlled by some other magic file - ~/.profile or ~/.ssh/environment or 
something.

Have you read the instructions here:
<http://svnbook.red-bean.com/en/1.5/svn.serverconfig.svnserve.html#svn.servercon
fig.svnserve.sshtricks.setup>

Last resort: Replace /usr/bin/svn & svnserve with sym-links to 
/opt/subversion/bin/...

Original comment by chris...@gmail.com on 4 Nov 2010 at 9:58

[GoogleCodeExporter]

Thank you very much for pointing me in the right direction. The following page 
has a good description of what to do: 
http://serverfault.com/questions/130834/svnssh-getting-bash-to-load-my-path-over
-ssh. In case it disappears, you can get to it and similar pages by searching 
"svn+ssh PATH".

What I needed to do to get it working was to add the line 
"BASH_ENV='~/.bashrc'" to my ~/.ssh/environment file on the host side (one did 
not previously exist). Then at the top of my .bashrc file on the host I added 
the lines:
PATH=/opt/subversion/bin/:$PATH
echo $PATH

This forces your path to include the location of the correct version of 
svnserve, even when running bash in non-interactive form (like inside svn+ssh). 
A great test to help get this working is to give the command:
ssh user@host "echo \$PATH"
This will show the path visible to svn+ssh. Note that the escape character \ is 
necessary, otherwise it will just return your local path. 

This totally fixed everything. Thank you so much for your help and I think you 
should mark the status of this issue as 'solved' or something other than 
invalid, so that others can find it more easily. 

Original comment by wolf.aar...@gmail.com on 4 Nov 2010 at 11:54