views:

115

answers:

2

I set up a fossil repository on a shared hosting account I have. I created a perl script fossil.pl that points to a cloned repository that I put up on the webspace. I set all the correct permissions (755). When I go to fossil.pl I get the web ui. Everythings cool. However I'm having a problem with pushes and hoping someone could point me to a solution.

When I clone a repository it sets a new password for me (Toby) in the new cloned repository. If I push to this repository online without changing the password it works fine, I can push up changes from my local machine to the online repository. However once I change the password for Toby (to something more easily remembered by me) I get the following error.

 Bytes      Cards  Artifacts     Deltas Send:           
 1810          9          0          2
 1Server Error: not authorized to write
 fossil: server says: not authorized to
 write

Anyone know why this is happening? Anyone know how to fix it?

A: 

Up until recently users and passwords were never cloned across. It's generally a good idea, when you clone, to make sure password on local and your remote are identical, and test it with a sync.

squeeks
I try to connect with the correct password for the cloned repository, its just that once I change it (to something more memorable) it causes an issue.
Toby Allen
+2  A: 

Fossil recently changed the details of how it saves passwords, which impacted the way authentication is done during clone, push, pull and sync.

One result of that change is that the initial password for the first user account created for you by the clone stores the password the old way, but changing any password updates it to the new way. To force all password records in a repository to use the new method use "fossil test-hash-passwords".

I would verify that both copies of fossil are after that revision, upgrading both ends as needed.

Note that if upgrading to the most recent versions available, you must do "fossil rebuild" on the server (and locally too for any clones) due to changes in the database schema. Since that is always safe to do, it is wise to do it after any upgrade.

RBerteig