Subversion moved to

To take advantage of the nicer Fisheye and to allow us to use Crucible for code reviews, I had to move the subversion repository to

All the history transferred over correctly, but all development going forward should be done against the new repository.  If you have the code checked out from sourceforge, please re-check it out from the new location:

Also, commit permissions were not transferred over, so you will need to create a new account in order to commit.  You can still check out in read-only mode anonymously, but you will need an account to write.  I would like to experiment with having more people commit directly now that we have access to Crucible for reviewing code.  I think it will be easier than funneling patches through me and give contributers the credit they deserve.  I am not sure exactly how the write permissions work, so if someone would volunteer to do a little testing of if/when they can commit (anonymously, then after creating an account) please let me know.

As an added bonus, the new svn repository is significantly faster than the one at sourceforge.


Is there any anonymous account because i can not checkout from url using eclipse

It should allow anonymous access.  What error are you getting? 

I can check it out from command line svn without being prompted for a username, but I am unsure if my authentication is being cached.

it’s allowing anonymous access to make a checkout from command line, but when i try to add new repository to eclipse it start annoying that i need to supply login and password to make a checkout through eclipse. Previous repository at sf was working ok.

I wonder if eclipse has some sort of authentication cache that it is trying to use.  I tried checking it out using eclipse->new project from subversion and it pulled my regular username/password from the subversion cache to check it out. Are you doing a fresh checkout, or did you do a relocate from the old repository?

I then cleared my authentication cache using tortoisesvn’s settings (since they were both using the same $HOME$/.subversion settings apparently) and re-checked out the repository with eclipse and it came down fine anonymously.  I was only prompted for a username when I tried to commit something.

It may be related to some other permission issues we have that is at least temporarily fixed up.  Give it a try again, and if you are still having problems try clearing any authentication cache you may have.


Thanks for advice but it still has some kind of authentication problems even on clean installation of eclipse (auth cache was also cleaned). Anyway i succeed to clone repository.

Very strange.  I anyone else having troubles or succeeding in anonymous checkout?

Another option is to create an account on and use that as your authentication information.  I have the permission scheme set up so that anyone with an account is able to both read and commit code.  My thought is that it will make it easier for people to get changes in without having to deal with the patch process, but we will still be able to maintain quality control by leveraging the crucible code review system on the site as well. 

It is just an experiment at this point, so if it doesn’t go well we may pull back to needing “developer” rather than just “user” permissions to commit, but for now feel free to authenticate as your account and commit any fixes you find.


I updated this page to reflect the correct subversion URL:

Great, thanks for catching that


I have a problem with the SVN repository (sometimes). When I update my local checkout of the branch subversion asks for a password and I can’t get passed it. When I want to update my copy of the repository I need to remove it and do a complete check out again.

Here is a copy of the process, svn starts updating but then asks for a password:

    C:\develop\3rdparty\liquibase>svn update U    liquibase-dist\pom.xml U    pom.xml U    liquibase-core-jvm\src\main\java\liquibase\snapshot\core\ U    liquibase-core-jvm\src\main\java\liquibase\snapshot\core\ U    liquibase-core-jvm\src\main\java\liquibase\executor\core\jdbc\ U    liquibase-core-jvm\pom.xml D    liquibase-integration-tests\src\test\java\liquibase\dbtest\ D    liquibase-integration-tests\src\test\java\liquibase\dbtest\sybase\ D    liquibase-integration-tests\src\test\java\liquibase\dbtest\sybase\ Authentication realm: <> Subversion Repository Password for 'chris': Authentication realm: <> Subversion Repository Username: quest Password for 'quest': ***** Authentication realm: <> Subversion Repository Username: Password for '': svn: OPTIONS of '': authorization failed: Could not authenticate to server: rejected Basic challenge (

Do I need to enter a specific username (like guest or anonymous) to get passed this?


I thought it should allow anonymous access. It’s odd it’s failing part way through.  If you have an account on that username/password should work.


Tried again this morning but the update failed again. I created an account and entered the username/password for it and update continued. The first file it tries to download after the username check was


which is new in the repository. Can you check if a svn update fails when it encounters a new file in a repository?

    C:\develop\3rdparty\liquibase> svn update U    liquibase-dist\src\main\resources\liquibase U    liquibase-dist\pom.xml U    pom.xml U    liquibase-core-jvm\src\main\java\liquibase\integration\spring\ U    liquibase-core-jvm\pom.xml D    liquibase-integration-tests\src\test\java\liquibase\dbtest\pgsql\ Authentication realm: <> Subversion Repository Password for 'c.wesdorp': Authentication realm: <> Subversion Repository Username: chris Password for 'chris': ******** A    liquibase-integration-tests\src\test\java\liquibase\dbtest\pgsql\ D    liquibase-integration-tests\src\test\java\liquibase\dbtest\firebird\

It should allow read access to all files, even new ones.  Thanks for figuring out the failing file.  I’ll look into it more.


Asked Jira support about the problem, but they were unable to duplicate it.  They were wondering if you had ever checked out or updated that repository with authentication, or if it had always been anonymous? Did you have the liquibase source checked out from the sourceforge svn server originally?

Has anyone else had similar problems?



I always did the checkout anonymously, until this issue occurred I did not even have a account.

The checkout is done with SlikSVN version 1.6.3 (SlikSvn:tag/1.6.3@38112) X64, on Vista 64-bit. When I check out the repository anonymous this problems occurs at one of the next updates. No changes are made to the local files.

The initial checkout (with svn co ) always succeeds, but the update (svn update) fails.


It happened again, doing svn update stops on a new file:

    C:\3rdparty\liquibase>svn update U    liquibase-dist\src\main\resources\liquibase.bat U    liquibase-dist\pom.xml U    liquibase-core-jvm\src\test\java\liquibase\serializer\core\xml\ D    liquibase-core-jvm\src\test\java\liquibase\parser\core\xml\ U    liquibase-core-jvm\src\test\java\liquibase\parser\core\xml\ Authentication realm: <> Subversion Repository Username: chris Password for 'chris': ******************************** A    liquibase-core-jvm\src\main\java\liquibase\integration\ant\ U    liquibase-core-jvm\src\main\java\liquibase\integration\ant\ U    liquibase-core-jvm\src\main\java\liquibase\integration\commandline\ ... continued

The support person at atlassian did do an anonymous checkout and update and it was working for them.  I was hoping it was just a weird fluke for you before…

Did you go back to an anonymous checkout, or were you still logged in when you did the update and it failed?


One more try then, i now have a situation which fails for me every time.

System specs:
Windows Vista 64-bit SP2
SlikSVN, svn, version 1.6.3 (SlikSvn:tag/1.6.3@38112) X64

To get it into the failure, I do check out revision 1167 because the next revision has a new file.

    C:\TEMP>svn co -r 1167 liquibase .... lots out output ....

    C:\TEMP>cd liquibase

    C:\TEMP\liquibase>svn info
    Path: .
    Repository Root:
    Repository UUID: e6edf6fb-f266-4316-afb4-e53d95876a76
    Revision: 1167
    Node Kind: directory
    Schedule: normal
    Last Changed Author: nvoxland
    Last Changed Rev: 1167
    Last Changed Date: 2009-09-23 03:58:37 +0200 (wo, 23 sep 2009)

    C:\TEMP\liquibase>svn update
    U    liquibase-dist\src\main\resources\liquibase.bat
    U    liquibase-dist\src\main\resources\liquibase
    U    liquibase-dist\pom.xml
    U    pom.xml
    U    liquibase-core-jvm\src\test\java\liquibase\serializer\core\xml\
    D    liquibase-core-jvm\src\test\java\liquibase\parser\core\xml\
    U    liquibase-core-jvm\src\test\java\liquibase\parser\core\xml\
    U    liquibase-core-jvm\src\main\java\liquibase\snapshot\core\
    U    liquibase-core-jvm\src\main\java\liquibase\snapshot\core\
    Authentication realm: <> Subversion Repository
    Username: chris
    Password for ‘chris’: ********
    A    liquibase-core-jvm\src\main\java\liquibase\integration\ant\
    … continued …

Maybe other readers can check this as well but if nobody can reproduce this it seems I am the only one with this problem…

Update: just tested this on a Linux machine I own; same actions, same result. When the update encounters a new file I need to authorize.


It may just be something weird with that revision.  If you do a checkout of the latest version of trunk and do an update, do you still get the error?


When there are no new files (only updates on a revision) i won’t get the error. Doing an initial checkout always works. Today i did not have the problem.
It does not always happen, but if no-one else has this issue I will just authenticate because then the issue does not occur.