The main reason to clone is that you might not have permissions as a commiter to the main repo, but you still want to be able to commit your changes locally, whether or not they will eventually be propagated to the main repo.
I decided to give a go at using Git instead of Subversion. I have been using Git for a while now, and although it can be very tricky at the beginning, it is a great system.
I am not going to go into the differences between the systems, cause a simple google search will provide a lot more information that I could ever compile on here.
So let's cut to the chase and see what I got so far, and what problems I'm having:
First thing to do is a google search! These are a couple of interesting links that I've found, and the process I followed in here was taken from those links:
[1]: How to cleanly migrate an svn repo.
[2]: Automating the authors file.
Git manages authors in a different way to svn, so one of the steps needed for the migration is a text file with the authors' names and email addresses. Although in the first link they create this file manually, there is a script in the second link to automate its creation.
From [2]:
Create author mapping file
Create a svn.authors file, which maps the svn author names to git author names:
#!/bin/bash
authors=$(svn log -q | grep -e '^r' | awk 'BEGIN { FS = "|" } ; { print $2 }' | sort | uniq)
for author in ${authors}; do
echo "${author} = ${author} <${author}@dev.java.net>" >> svn.authors ;
done
I will not go into many details here because both links are very clear. What I did to clone, step by step, was:
1. run the authors script and modify the output if you have real information about the authors. To run the script as it stands, you will need a local svn copy of the original repo.
2. cd to the location where you want to have your git repo.
3. create a temporary location for the code: mkdir wonderland_temp
4. cd wonderland_temp
5. git svn init http://openwonderland.googlecode.com/svn/trunk --no-metadata
6. git config svn.authorsfile /location/to/your/svn.authors
7. git svn fetch (This step is going to take a good couple of hours!)
The last step will get rid of all the superfluous svn information and leave a clean git repo. The problem here is that it also gets rid of a bunch of empty directories that are needed to compile, so if you do 8, you will have to recreate those folders.
8. git clone wonderland _temp wonderland
Some Problems:
A weird thing happens when I try to compile wonderland core and wonderland-modules exists at the same level. For some reason the build tries to compile the audio-recorder module from the modules directory, and this fails when it tries to hit the ContentRepository class.
The failure in itself makes sense, or so I think, because it is trying to compile a module that depends on part of the core, when the core has not finished compiling. What puzzles me is that the core build triggers compilation in the modules tree??? this is very strange. Stranger is that if I get rid of the wonderland-modules directory, the build runs like a charm!
It might be me, or something in my system, but I guess the only way to know is to track down the build scripts, which I intend to do as soon as I have time for it.
Other than that, when I run the new server, I run out of memory, which does not happen in the svn tree. I will need to track this down too.
These instructions will provide you with a local copy of the repo that you can use for personal purposes. If you want to share this 'main' copy with other people, say at your company, you will have to check how to publish a git repo; some ideas here:
Have fun!
[UPDATE]: Just tried the process under Windows 7 + Cygwin and all goes really smooth. Server compiles and no out of memory errors (the ones noted above were on MacOS X).
[UPDATE 2]: The compilation problems were only in my machine, and due to the fact that the empty directories were not present. The main build checks for the wonderland-modules project, and in case of existing, it builds it too.
No comments:
Post a Comment