Best Practices: Repository Resets

By Ben Collins-Sussman, Open Source Team

Over in the google-code-hosting discussion group, we see a lot of users asking us to 'reset' their Subversion repositories back to an empty revision 0, tossing away all data and history. Sometimes there are good reasons for doing this; however, much of the time we're getting these requests for the wrong reasons.

Users who are new to Subversion often get the idea that the global revision number has some sort of special meaning — that it somehow measures the "maturity" of the software. In fact, the revision number is just a dumb counter that measures moments in time; it actually has no special meaning. If you accidentally mess up a code import or don't like the way things are arranged then just rearrange things with 'svn mv' or delete everything with 'svn rm' and start over! There's no need for the repository's history to be "pure." The repository is simply tracking changes over time (even restarts and mistakes), not describing the evolution of flawless software.

There are typically only three legitimate reasons for resetting a repository:

1. Something really sensitive, confidential, or illegal was accidentally committed, and now exists in the history forever.


2. Some HUGE garbage file was accidentally committed, and now a ridiculous amount of disk quota is wasted.


3. A project owner wants to replicate a prior repository into the repository, using the 'svnsync' tool (which requires an empty repository at revision 0).

If your request fits one of these categories, then please drop the Project Hosting team a note on the public googlegroup, or, if it's a sensitive matter, mail us privately. We'll ask you to remove everything in the repository, thus proving you're a legitimate project owner and not someone forging emails, and then we'll reset your repository.

Another tip: when a project is first created, it begins life at revision 1, with empty /trunk, /branches, and /tags directories. A project at revision 1 can be reset to revision 0 by project owners themselves; you'll see a bubble on the right side of the 'Source' tab advertising this fact. (This feature makes it easy for newly-created projects to prep the repository for receiving data from 'svnsync'.) Once a repository is changed and goes beyond revision 1, however, resetting a repository is no longer self-serve; you'll have to ask the administrative team for a reset.

One final tip: the wiki feature saves wiki pages into the /wiki directory of the Subversion repository. This means that if you make a wiki change while svnsync is populating your repository, you'll break the sync halfway through. You'll have to request a repository reset and start the sync all over. Be careful!

CSSJanus: Helping i18n and LTR to RTL

By Dion Almaer, Google Developer Programs

Have you ever been asked "but what about a Hebrew version?" Lindsey Simon has, so he decided to write a tool that would help with the task.

CSSJanus is CSS parser utility designed to aid the conversion of a website's layout from left-to-right (LTR) to right-to-left (RTL). The script was born out of a need to convert CSS for RTL languages when tables are not being used for layout (since tables will automatically reorder TD's in RTL). CSSJanus will change most of the obvious CSS property names and their values as well as some not-so-obvious ones (cursor, background-position %, etc...). The script is designed to offer flexibility to account for cases when you do not want to change certain rules which exist to account for bidirectional text display bugs, as well as situations where you may or may not want to flip annotations inside of the background url string. CSSJanus itself is not always enough to make a website that works in a LTR language context work in a RTL language all the way, but it is a start. We sat down with Lindsey to talk about the motivation of the tool, the challenges behind it, and a screencast showing it in action:




Check out a running Django-ified webapp version, and for the greatest detail of what gets flipped in CSS Janus, please have a look at the unit tests.

Google Summer of Code: Mentoring Organization Applications Are Open!

By Leslie Hawthorn, Open Source Team

Ready to find the best and brightest students to contribute to your open source software project this summer? The Google Summer of Code™ 2008 program funds students worldwide, pairing them with mentors from the FLOSS community. We're now accepting applications from open source projects who wish to act as mentoring organizations, and the application deadline is Wednesday, March 12, 2008. We'll post a list of approved organizations on the Google Summer of Code page on Monday, March 17th. Students will have a week to discuss application ideas with their potential mentors before student applications open on Monday, March 24th

Check out our FAQs for a preview of the application. And remember, if you have any questions, you can always find us in the Google Summer of Code Discussion group or in #gsoc on Freenode. Best of luck to all of our applicants!