Futurice Blog

Migrating SVN repos (with full history) to Git - A story from the trenches

I recently ran into an interesting VCS-challenge. Combine two separate SVN repositories into one, preserving the relevant part of the history in the process. The challenge at first sight seemed to be straightforward, but turned out to be quite a hairy deal. As usual, a software project cannot stand still for long, so active development was done during the whole transition. I will describe some of my findings, in the hope that the next person trying something similar does not have to bump into all the same obstacles in the process. But first, a small warning. This post will be longer and more technical than the usual Futurice blog post, so unless you feel like taking a deep dive into the mysteries of VCS, you should stop reading now. Consider yourself warned.

Here are a few Do's and Don'ts for the impatient. I will then discuss the process in more detail below.

Don'ts

• Combine SVN repositories using SVN tools (like svndump)
• Replay the history one commit at a time
• Try to execute clever modifications of the histories in the repositories
• Have several VCS in parallel for more time than is absolutely necessary

Do's

• Switch to a more capable system in the process (git, hg, bazaar, ...)
• Import the full original histories, so you have a way to recover an old build
• Map the SVN usernames to match the new naming scheme
• Execute all and any major reorganization of the directory structures before export from SVN

The two repositories that needed to be combined were a server repository and a separate client repository. Managing the dependencies and release cycles between the two had turned out to be too cumbersome for a fast paced, agile project, and it was slowing us down unnecessarily. The complication in the task was that the client repository had originally started as a branch of a larger codebase. The original small branch turned into a larger project, and soon matured to be a fully independent project, without any proper relation to the original parent project.

Failing approach number 1: svn admin dump and load

SVN actually provides tools for combining several repositories. The process of using svn admin dump and load preserves the full history of the repositories. The process does, however, not cope with any conflicts for paths. I don't consider myself an SVN expert, and after consulting some experts on the topic, we decided that this was way too error prone and cumbersome to be done in practice. For full repository dumps the approach might work, but since we wanted only the relevant parts of the history, i.e. one branch, this was not a suitable approach. One of the repositories contained approximately 25000 revisions, and the other one well over 3000, so the overhead of the extra changesets and the probability of multiple conflicts on the paths was too big a risk to take.

Failing approach number 2: Rewrite and replay

I have been using git-svn successfully as a SVN client for well over a year now, so the natural next approach was converting the repositories to git, and replaying the changes back to one of the SVN repositories. This approach could also be scripted in SVN-only fashion, but having the full history in git would make the process much faster. Git-svn allows for extracting specific branches into the repository, which was one of the original goals of the migration. The problem with replaying changes was the hosted SVN server we were using. We did not have shell access to it, making scripting much harder. The SVN server automatically assigns the unix username to the commit, so had I just replayed the changes, the history would have shown me as the only collaborator. As a compromise, we agreed that we could instead include the original commit data in the new log message. Svn blame would be broken, but at least it would be possible to find the original author in the log. Git has the very handy filter-branch command, which lets the user do batch changes to the history. Changing common history is normally not a recommended approach, but in this case we saw it as the only option to keep svn as a viable solution. Git-svn adds some metadata to the commits, so they end up looking like this:

commit fedcbaf1821677f02c1c36adb99f5ed3d5a5728d
Author: unix-user
Date: Fri Jan 14 16:36:46 2010 +0000

LOG MESSAGE

git-svn-id: svn+ssh://SVN-SERVER-AND-REPOSITORY@22222 11e32337-3d48-0410-9457-8905d971a4a1

The git-svn-id contains the original repository information, as well as the revision number of the SVN commit, i.e. 22222 in the example above. With a little bash+perl magic below, the log message could be made much more readable.

#!/bin/bash
git filter-branch --msg-filter '
perl -pe "s/^\s*git-svn-id: [^@]+@(\d+) .*$/Revision:\t\$1/g" &&
echo "Author:\t$GIT_AUTHOR_NAME" &&
echo "Timestamp:\t"`perl -e "use POSIX strftime; print strftime(\"%Y-%m-%dT%H:%M:%S\", localtime(\"$GIT_AUTHOR_DATE\"))" `
' $@

The operation takes several hours to run, even on my SSD equipped machine, but considering the one-time nature of the operation, this was acceptable. Filter-branch is also not restricted to changing log messages. It allows almost anything to be done to the history. For example, we played with the idea of moving the whole history of one of the projects to a suitable subdirectory before the merging, but found the approach too intrusive. It might compromise our ability to recreate earlier builds at a later time. However, figuring out the power of filter-branch made this trial and error a very educational one.

The winner: Move the whole project to git

The results of rewriting the history were very promising. The flexibility of git, however, impressed the development team, and finally we decided to switch over completely to the world of DVCS. This way we could preserve the full history with the full commit information without having to rewrite log messages. We pondered over rewriting the history to reflect the new structure, but again rejected the idea for the same reason as before.

The task of combining two or more git repositories is easy. It is possible to pull in the changes from any unrelated repositories. The initial cloning of the SVN repositories is quite straightforward. Co-operating with svn, however, makes synchronizing the repositories between git and SVN quite a big problem. Git-svn uses rebase strategy to synchronize the local repository with the SVN repository. Rebasing keeps the history linear by appending any changes done locally in git to the end of the chain of SVN changesets. This is not a problem as long as there are changes only on either git or svn, but maintaining changes in two systems becomes very work intensive after a while. I unfortunately did the mistake of creating the authoritative git repository at this point, contrary to the recommendation in the git-svn manual. At this point I also moved a lot of directories around in git, laying out the directory and project structure. The changes could not be committed back to SVN, thus laying out a stony path of synchronization work for myself. The transition took about two weeks, so there were a lot of changesets created on the SVN side, all of which had to be synchronized to git.

In order not to create discrepancies in the now authoritative git repository, it was no longer possible to rebase the handful of changesets with the new structure on the SVN changes, but instead I had to rebase the SVN changes on top of the git changes. The local repository in git makes rebasing easy, as even this complex operation can easily be reverted and started over. The git reflog command is of tremendous help in the process, keeping a log of all the changes being made. Unfortunately, my changes in git introduced some interesting error cases for the rebasing.

Git only tracks file contents, but not directories. Git tries to deduce which files have moved from one place to another. SVN on the other hand, treats both directories and files as first class objects, and only stores the file content as a property of the file-object. This distinction is very important when making git and SVN co-operate in the way that we were doing here. Git managed to do the rebase and deduce the new location of any old files being moved, and was thus able to carry on changes to the correct files. This, however, does not work properly for new files that were created in SVN after branching to git. All the new files were left at their original path, relative to the root of the repository. The fix was to manually move the directories to the new structure. Fortunately there were no complex renames of files in SVN, as this might make synchronizing significantly harder.

Having noticed the problem during the first repository migration made me change the strategy for the second one. Instead of just rebasing the changes, I decided to first revert any changes to the directory structure, in order to reduce confusion over new files in the repository. Revert is a safe, non-destructive operation as it creates new reverse changesets at the end of the history, thus keeping the history intact. Having reverted the directory renames, I was quite easily able to create a clean and linear history by rebasing all new SVN changes to git. This new approach saved me several hours of work of tracking down any possible missing files or conflicts due to git being unable to locate all changed files.

One final problem we had was a handful of late changes in the SVN repository. Once the rebase had been done, there is really no proper way to repeat the process. All the changeset ids get changed due to the rebase, so trying to do the same rebase a second time is bound to fail. Fortunately git supports cherry-picking, i.e. moving individual changesets from one tree to another. It was quite easy to loop over the missing changesets and cherry-pick them one by one to the new branch. Cherry-pick supports copying multiple changesets with a single command, but since there were only a handful of changes, I did it manually. This is the process that will have to be taken should there be any changes to the SVN repository later on. Because of this, however, it is very important to tag the key changesets to make sure it's easy to figure out which changesets, if any, have been fetched after the rebase operation.

The final step of the process was to merge the two separate branches into a single development branch and start hacking away. The positive sides of this approach is that we now have the full history of both the repositories, so we will be able to recreate any earlier build. We also managed to remote all the extra and non-related branches from the repository in the process. This reduced the total number of changesets to under 50%, which is really valuable since it reduces the noise in the logs.

Improvements

There were, of course, quite a few things that could have been done differently, and in a much better fashion. The following two are the most prominent. The biggest mistake was to create and publish the authoritative git repository too early. Had I not done that, most of the extra work with rebasing and moving files in git could have been avoided. I probably spent an extra working day or two on the task because of this. The optimal solution is to migrate to git in one step, without having to migrate changes between repositories.

The second mistake was to not convert the unix usernames in the authors of svn to proper name + email pairs. Git-svn has an option of doing this by providing a file with mappings between SVN usernames and git usernames. Since this was not done in the first place, the history will now contain entries with both unix username based authors and name+email authors.

Retrospective

The project has now been using the new VCS and the new project structure for about a month. The reactions have been overwhelmingly positive, although unlearning SVN ways and embracing the git way has been challenging from time to time. Git is quite a lot more complex than SVN (or Mercurial), but given that most developers on the team had no previous experience with git or DVCS in general, there have been very few mistakes. The support for git on Windows is still a nuisance, as all the tools seem to do things a bit differently. So far we've used Egit for Eclipse, TortoiseGit and Git Extensions. On OS X the situation is much better, with tools like Git Tower and of course old trusty bash with command line git. For Windows users, Mercurial does seem like a route of less resistance, though.

Git-svn is a great tool for a task like the one I have described, even with the problems in the process. A second go at the same task would probably be much easier after learning a number of things the hard way. Many of the problems I encountered were really things that you only know from previous experience, either your own or somebody else's. I would, however, be glad to hear and learn from you if you have done something similar and feel that you've got a better way of doing things.

-Kai Inkinen

Posted by Ville Saarinen 

From Good to Even Better

Futurice was founded on a few ideas: no useless bosses, constantly being able to develop oneself, and to have fun at work. After ten years, we have extremely happy customers and a good business, and we are at the top in job satisfaction.

The goal of the Great Place To Work survey was not to compete with others, but rather to benchmark ourselves with other great workplaces to obtain information on how to become even better. The #2 position on our very first try is a very good result and even better when you look at the other cool companies on the list. Every current and former Futurice employee has a part in this, but I would like to say special thanks to Lenita, Lotta, Mikko and Tuomas for their determined work.

But this is just one step on our way to becoming the most wanted employer in the IT sector  globally. Sounds daunting? It should. The road will be full of exciting events, obstacles and really awesome possibilities for everyone to participate and grow.

One of our main key drivers at Futurice has been totally open communication inside the company. Our HR team will start to blog about our ways of creating and sustaining the work atmosphere. Stay tuned.

Hanno Nevanlinna
The proud new grand coach of HR

Posted by Ville Saarinen 

Quality Assurance is dead ... long live Quality Leading

In many projects there is a QA person or persons responsible of ‘assuring’ quality. This is mainly done by testing and writing many reports. I will argue here that this mostly is a waste of time and should not be done anymore.

Lets start off by looking at quality assurance and where it comes from. It initially comes from from manufacturing where the QA would ensure that certain properties of a produced product fall within a predefined range of acceptable values. We in the software development industry took that system and adapted it for our purpose. With requirements and specifications which have to be smart so we can assure the quality. This is in essence a wrong approach as software development is a creative process. Quality is an immensely complex thing and assuring it is a myth the only thing we can do is trying to the best quality for the buck.

It is therefore not a smart thing to just have QA sit in the back waiting till something can be tested. The role of a tester is 3 fold.

First is to find information about the product being developed. This information is mostly bugs, but can also be information developers needs for further development. The method should fit the project, but writing lots of plans and test cases is hardly ever more effective than session based testing.

The second role is to be an advocate of quality improvements. An advocate meaning that the tester should actively participate in product planning, both in the planning in terms of the feature set and planning in terms of possible choices of implementations. The tester should promote implementations with reduce complexity, promote technical stories which are aimed to reduce technical debt. In a sprint planning for example a tester could advocate refactoring some piece of code based on testing results the previous sprint or promote a user story which mitigates a potential unstable application behavior  or discouraging a story which increases the complexity a lot. In short it should be the aim of the tester to maximize the quality and lead efforts to improve the quality.

The third role is to inform stakeholders of the quality so they can make an informed decisions regarding releases etc. How this information is presented has to be agreed, but it should be a holistic picture and not a set of metrics. At the end the tester should present his finding and his opinion of the quality to the product owner. It is up the him or her to say if this is acceptable or not. If the quality in not acceptable, the tester should suggest ways to improve the quality.

-Peter Tennekes

Posted by Ville Saarinen 

Smörgåsbord or À la carte for the end-users?

How are values embedded into technology, and should designers care?

One of the popular examples of values in technology is the (in)famous story of how supposedly the motorway bridges to Long Island were designed to keep the less wealthy people outside the island’s resorts and beaches (see Winner L (1980) “Do artifacts have politics?”). The story goes that the bridges’ tunnels were so low that a bus could not fit into them, and hence, unwealthy people who rode public transport could not enter. The bridge embedded a set of social values.

The story is too good to be true, and a good argument against the Long Island case is made by Joerges (Joerges B (1999) “Do politics have artifacts?”). Nevertheless, the idea that supposedly neutral technology embodies a set of values is the takeaway from the story and worth pondering, so lets ponder.

Let us take a look at two rival smart phones from few years ago: the Nokia N95 and the first iPhone. Both entering the public consciousness in 2007. What kind of values about technology use these embody?

The Nokia N95 had all the bells and whistles: GPS, 5MP still camera, VGA video camera, live video telephony, mp3 player, 3G network, WiFi, Bluetooth, IrDA, web browser… The engineering philosophy trickling between all the features and functions was that “we provide all the latest technology, the user selects what he/she needs”.

The iPhone in 2007 did not have a video camera, no GPS, and no 3G. At the time it was puzzling that such a limited device became popular. Of course, as all iPhone users know, Apple chose to make the few functionalities the phone had extremely attractive to use – especially web browsing. The overarching designer philosophy was “we decide what you need, and superbly design for those needs”.

For me the N95 philosophy resonates with my engineering background. Feel free to disagree, but typically in engineering culture the idea is to serve the user or customer by providing complex technology on a silver tray. This approach is very egalitarian, i.e., equal and even emancipating for the users. Perhaps not surprisingly the N95 was created in Finland, a Nordic country famous for its social welfare and democracy.

The iPhone philosophy is different, and familiar to Apple users in general. It is an enlightened dictatorship in which the designer(s) knows best and makes it perfect for the end-user. The end-user is pretty much left with a choice of “take it or leave it”. And it seems that many people “take it”. For those who don’t know, Apple is not from a Nordic country but from Silicon Valley, US.

My point is about user-centric design:

Which one is user-centric? A) to give the user a choice out of a smörgåsbord of technology; the user has power to choose, but perhaps the number of options is paralysing the usability. B) to understand the user and make decisions on his/her behalf and design killer usability for the limited à la carte menu?

-Risto Sarvas

Posted by Ville Saarinen 

First year in Germany is a huge success

After one year in Germany Futurice GmbH can draw a positive balance. Revenues from Germany made up to 20% of the company’s total revenues during its first year of operation, much of it from new customers.

Futurice GmbH was officially founded on May 20th 2010 and is a subsidiary that is fully owned by its parent company Futurice Oy. Futurice’s customers include-but are not limited to-global telecom operators, OEMs and media houses. Futurice Germany is looking to further seek out new industries where its skills and knowledge can be applied. “We want to operate close to our customers. From Berlin, we can better serve our Central European customers,” comments Sampo Hämäläinen, CEO of Futurice GmbH.

Founded in 2000, Futurice has been listed by the Deloitte Technology Fast 50 for the past seven years, being Finland’s fastest growing tech company in its category in 2008. Today, the company employs approximately 130 software engineering professionals and is looking to expand internationally. The new Berlin office is situated at the very heart of Berlin and employs more than a dozen Futurice employees, both Finnish expats and locally recruited software specialists. Futurice’s customers appreciate rapid project delivery, transparency as well as flexibility and agility enabled by small and efficient project teams. There is a clear demand for the service offering developed by Futurice.

Regarding the long term strategy Hämäläinen says: “Our vision is to be the most wanted digital service developer in Europe. Germany has an important strategic role in implementing this vision of growth, but not at the cost of profitability or customer satisfaction”.

Berlin provides a competitive location for Futurice’s expansion, both in terms of costs as well as geographic connections. Moreover, as a growing centre of digital media, the city offers Futurice an excellent environment for the diversification and development of its high-end expertise.

Erstes Jahr in Deutschland ist ein voller Erfolg

Nach fast einem Jahr in Deutschland kann die Futurice GmbH eine äußerst positive Bilanz ziehen. Die Umsatzerlöse aus dem ersten Jahr in Deutschland machten bis zu 20% des Gesamterlöses der Futurice-Familie aus, ein Großteil davon aus den neuen Kunden.

Die am 20. Mai 2010 gegründete Futurice GmbH ist eine vollständige Tochtergesellschaft der finnischen Futurice Oy. Zu den Kunden von Futurice zählen auch, aber nicht ausschließlich, globale Telekommunikations-unternehmen, OEMs und Medienhäuser. Futurice Deutschland sucht nach neuen Branchen, in denen die Fähigkeiten und Kenntnisse des Unternehmens angewandt werden können. “Wir wollen nah bei unseren Kunden arbeiten. Von Berlin aus können wir die Anforderungen unserer zentraleuropäischen Kunden sehr gut erfüllen.”, so Sampo Hämäläinen, CEO der Futurice GmbH.

Gegründet im Jahr 2000, wurde Futurice in der „Deloitte Technology Fast 50“-Liste der letzten sieben Jahre aufgeführt und war 2008 Finnlands am schnellsten wachsendes Technologieunternehmen. Heute beschäftigt das Unternehmen rund 130 Software-Engineering-Fachleute und expandiert international. Das neue Berliner Büro befindet sich im Herzen der Stadt und beschäftigt mehr als ein Dutzend Mitarbeiter, sowohl finnische Expats als auch deutsche Software-Spezialisten. Die Kunden der Futurice-Familie schätzen die schnelle Projektabwicklung, Transparenz sowie Flexibilität und Agilität des Unternehmens. Ermöglicht wird dies durch kleine und effiziente Projektteams. Es gibt eine klare Nachfrage nach dem Service-Angebot von Futurice.

Zur Zukunft der Futurice sagte Hämäläinen: „Unsere Vision ist es, der gefragteste Entwickler von digitalen Services in Europa zu werden. Der deutsche Markt spielt dabei eine wichtige strategische Rolle, aber nicht auf Kosten der Rentabilität und Kundenzufriedenheit.”.

Berlin ist ein wettbewerbsfähiger Standort für die Expansion der Futurice, sowohl in Bezug auf die Kosten als auch die geographischen Verbindungen. Außerdem ist die Stadt ein wachsendes Zentrum der digitalen Medien und bietet  Futurice ein hervorragendes Umfeld für die Diversifizierung und Entwicklung von High-End-Expertise.

-Alexander Kluwe

Posted by Ville Saarinen 

Why Personal Virtual Servers?

As Olli mentioned before the holidays, our IT team decided to provide personal virtual servers as an employee benefit. In other words, anyone can now set up their own hosted server to be used however they want (as long as it’s not work-related). I wanted to briefly follow up on why this benefit is such a good idea.

First of all, the infrastructure to provide such a service was already in place. Our IT team is already skilled in administering virtual servers and the software needed to allow anyone to create and administer virtual servers was already in place.

The second reason is cost. After the initial setup, very little administrative work is required by the IT team. Of course, renting a physical server is not free, but compared to renting a virtual server for each employee, it’s a much more cost effective alternative. A virtual server costs about 50 euros per month if rented separately, but with our solution, the cost comes to less than 10 euros per month per server.

Finally–and most importantly–giving employees a virtual sandbox allows them to experiment, to try out new technologies, to actually build something that they’re passionate about. The best way to learn something is by doing, and a personal server is a risk-free way of giving everyone a chance to do this. Employees benefit since they don’t have to spend money if they want to try something and Futurice benefits from having happier employees who constantly improve their skill set. Win-win.

Posted by Ville Saarinen 

Coding Postures

While taking some photos from around the office, I decided to snap a few pictures of people tapping away at their computers. Here's the result.

(Note to all ergonomics professionals: take this image with a grain of salt.)

Posted by Ville Saarinen 

Personal Virtual Servers

Recently, we decided to provide personal virtual servers as an employee benefit. After briefly evaluating typical virtual servers provided by hosting companies, we ended up with an above average configuration. We wanted to provide at least 1 gigabyte of memory, over 50 gigabytes of disk space, a fast enough Internet connection and adequate processing power. Because delivery times for server hardware are rather long (on the order of a few weeks) and the setup is more difficult (requesting a new IP block to our server room is quite an inconvenient and slow process), we decided to rent a dedicated server, including 2 x 80 GB SSDs, 2 x 1500 GB SATA disks, 24 GB of DDR3, 2 x quad core Xeon processors and a 1 gbit/s Internet connection.

After changes to our installation server (FAI) and to our internal virtual machine management tool (also known as VIMMA), we were ready to go. If you ever stumble upon a link to futupeople.com or futupeople.mobi, you know it’s ours. As soon as the first server is full (23 virtual servers), we’ll rent the next one.

We also wrote the following usage policies:

• No work related stuff.
• Use your own judgement.

Short and simple. We trust our employees.

Speaking of VIMMA, some time ago we streamlined the process for handling our work-related virtual servers. Whenever someone needs a virtual server, he (or she) can just go to VIMMA and click “Create a new virtual machine”. The new machine is automatically installed, up and running, and the creator is notified by email, all in less than 30 minutes.

Another great thing is that the creator – and all other employees with access to the server – can grant or revoke access for others using a simple web application. When a new person joins the project, any old member can modify the access control lists. No bureaucracy (but automatic audit logs of course), no approvals from managers, no requests to an outsourced IT department (we don’t have an outsourced IT department at all).

Going forward, the next large project for the IT team is further development of an internal search engine – for network disks, our wiki, bug tracker, source code repositories, Yammer posts, Basecamp data, and so on. Currently, a prototype has already been implemented using Solr.

-Olli Jarva

Posted by Ville Saarinen 

Tightening the Web Around Software

What started as a system with isolated points of access is now weaving into a tight fabric. That is, instead of surfing the Internet, we are increasingly immersed in the waves themselves. However, simultaneously the fright of drowning is diminishing as technology becomes a part our lives –- and not the other way.

Web itself is no longer a synonym for a browser. Web is but the facilitating structure that enables client software to share and consume information. Web pages, of course, remain such clients, but in addition we now have countless applications built on numerous other platforms. The motivation behind this phenomenon is most commonly either gaining access to some information only available on a certain device –- such as accelerometers –- or need to package the application in a certain way in order to put it in, say, AppStore.

With this transition arise new challenges. The former prevailing issue of browser compatibility is steadily fading into history and is giving room to a new kind of fragmentation of technologies. We are already living in a world filled with a spectrum of processor architectures, embedded operating systems and physical screens of different sizes. No longer is it possible to have one portal with only cosmetic tweaks to accommodate this variation.

However, unless one platform will one day rule the realm of software, I believe we will see a compromise emerge. What I mean is, it requires far too much effort to create a client with similar behavior for each of these ecosystems. Was there a solution that offered enough, while providing a suitable compatibility across platforms, it would be the eventual winner. This is simple evolution that the markets dictate.

There seem to be two plausible heirs to the Web 2.0 that fit the description. Namely, they are Adobe AIR and hybrid applications.

With Adobe AIR it is possible to directly package a web application (HTML5, JS and/or Flash) into an installer package that the AIR Runtime installs and executes. Essentially the same code can be run with access to all kinds of native APIs and local storage on any platform for which Adobe has provided the runtime. However, currently these platforms only include Android in addition to the usual desktop operating systems. In this sense it does not alleviate the dire situation.

Another approach is to stretch the traditional web a bit further. In all modern platforms it is possible to embed HTML5 inside of a “real” application, and contrary to the past, they also behave consistently. By only building the bells and whistles natively on top of the core functionality implemented in web technologies, it is even today possible to increase the amount of shared code between different applications –- thus reducing the amount of total work. However, while this sounds like the perfect cup of tea, the native wrappers still require quite a lot of expertise to develop for someone just starting and the overall architecture can easily go horribly wrong.

We are still far from an optimal solution, but it would certainly seem that the web as we have grown to know it is not disappearing but is rather becoming a fundamental building block of future software. Expect the web to be dissected and reassembled into a new world of software.

-Timo Tuominen

Posted by Ville Saarinen 

Futurice Germany at MoMo & iPhone Developer Conference

I’m continuing from Juha’s post about Futurice activities in Tampere with our next week schedule in Germany.

On Monday (Nov 29th) Futurice is sponsoring Mobile Monday 5 years in Germany -conference in Berlin. After that you can meet us and see Michael’s surprising presentation in Köln at iPhone Developer Conference (Dec 1-2nd).

Hope to see you in one of these events!

-Sampo Hämäläinen

Posted by Ville Saarinen