I’ve begun playing with git over at github by importing Reve’s source.
Eventually I will do away with subversion and trac and move to github for Reve completely. Trac is not very good and often locks up.
As I’m still new with git and github I’ll have to keep contributions to a minimum since I don’t know exactly what I’m doing.
Had my first bug report today about the to_i method I made on the String class breaking Rails migrations because leading zeroes weren’t being treated nicely in my method: "001".to_i # => 1 and fails the test 1.to_s == "001" and so a String was being returned fromto_i. Crap.
I don’t think that I need the method anyways (I’m going to spend part of today to make sure with more tests!) so I’ve removed it and tagged Release 80 and uploaded the gem to RubyForge. It should be available to gem update or gem install shortly.
This release also has a larger test coverage and some other unnecessary methods were pruned. Check it out!
A quick note to announce that the Reve Trac is online. Tickets can be submitted and source browsed.
A new revision is coming shortly with vast improvements in documentation.
It’s coming. All I have to do is zip the release up and update the RDoc documentation.
This fully supports the API Version 2. Next tasks on Reve include setting up a Trac as well as refactoring a lot of the methods (corporate and personal methods are almost always identical but wrapped in different classes). I also want to add the ability to save and feed the library your own XML.
Look for Reve revision 39 before the 23rd of December.
I failed in my svn migration. I kept getting checksum mismatches. Oh well.
I’ve admitted defeat and decided to just create a fresh blank repository and svn import my code.
Let this be a lesson: Use a proper SVN repository from the start and headaches will be avoided!
Today I finally managed to migrate my Evedb.info SVN repository from an internal box (boron) to my repository at Dreamhost (Home to Reve, too). It is really simple to do: Just copy the local repository files from Subversion to the new repository base. This means the conf, dav, db, hooks and locks diretories.
The problem comes when one revision is copied (Call it revision 10) and is checked out to another machine (phosphorus), development is done, checked in (Dreamhost’s Revision 11) and stupidly, development is also done on the local copy (boron) and checked in (Local revision 11). And just like that the migration away from a local file:// type.
It’s a nightmare to sort but I’ve finally got it sorted and protected with an off-site source and SSH key file.
The moral is: Plan ahead, don’t be stupid, and never make commits when you’re really tired.
Powered by WordPress