Frågar du mig har den traditionella annonsen fortfarande en plats  - OM:

- du har en kanal att sätta den i som når din målgrupp. Ex – din målgrupp är nyföretagare i Kronoberg och kanalen är ett nyhetsbrev som skickas ut till endast dem, med massor av matnyttig information för nyblivna företagare.

- Den kan förväntas ge en bra ROI  - return of investment. Överdrivet exempel: En annons som kostar 20 000, om du vill sälja anteckningsblock för 20 kr st till nystartade företag i Kronoberg, är knappast en rimlig investering. Då skulle man ju behöva sälja 1000 block till en förhållandevis liten målgrupp för att överhuvudtaget täcka kostnaden.

- Det inte är för många som vill sälja samma sak som du till samma målgrupp, i samma kanal.

Mycket annat spelar såklart roll om en annons ska bli en succé eller inte, men min första annons får åtminstone godkänt på alla tre punkter ovan och jag hoppas på att förvalta mitt utrymme väl. Vad tycks?

My current problem is I have quite a lot of projects and they are either under active development or developed in the past but only a few projects are kept in version control (Google Code SVN). Now I need a local VCS that helps me to keep track of changes of all those projects.

The first VCS candidate comes in mind, a centralized VCS, that is SVN. It’s not hard to organize my projects in an SVN repository:

Repository
|_ trunk
|     |_ Project-A
|     |      |_ README
|     |      |_ ...
|     |
|     |_ Project-B
|     |      |_ trunk
|     |      |      |_ LICENSE
|     |      |      |_ ...
|     |      |_ branches
|     |      |_ tags
|     |_ ...
|
|_ branches
|_ tags

This structure represents 2 most common ways to manage multiple projects in an SVN repository. That is, a project may have either monolithic layout (e.g. Project-A) or project structural layout (e.g. Project-B) and all of them can be put in trunk. In order to work on these projects, I simply check them out to my current working folder (e.g. Eclipse workspace):

svn checkout /path/to/repository/trunk/Project-A /path/to/workspace/Project-A
svn checkout /path/to/repository/trunk/Project-B/trunk /path/to/workspace/Project-B

Now, what I have in my workspace are:

Workspace
|_ Project-A
|      |_ .svn
|      |_ README
|      |_ ...
|_ Project-B
|       |_ .svn
|       |_ LICENSE
|       |_ ...
|_ ...

With this directory structure, I can start working on any projects and Eclipse IDE doesn’t bother to complain anything about wrong projects location. All changes from an individual project would be easily contributed back to the repository by issuing svn commit commands… And that is what I really want!

So the SVN is fit very well in this situation and I do think for a single developer project, SVN is the best source control out there. However, as you would have heard, git is awesome! Let give it a try…

How git helps me to reach my goal? How can I keep track of all changes in place? How to organize all those projects in a git repository so I can easily clone them to my workspace later on?

I asked this problem to a guy who claims to be an advanced git user and he told me something like: You had better understand the concepts behind git and forget what central VCS gave you, dude! Oh geeeeze!! I had known & understood git’s philosophy since I first heard about git! Now I just want to know which techniques be used to get my work done! Right now, I have found a few solutions but none of them really have convinced me yet.

Solution 1: Branching ~ very stupid & ugly

Repository
|_ .git
|     |_ objects
|     |_ refs
|     |    |_ heads
|     |          |_ master
|     |          |_ Project-A
|     |          |_ Project-B
|     |          |_ ...
|     |
|     |_ config
|     |_ ...
|_ ...

The repository is a big git repository because it holds all of my projects’ data inside. However, again, what I want is a way to clone them, one by one, into my workspace folder. To obtain this, each project should have its own branch and the master branch should be empty all the time so whenever I want to add a project to the repository, I can do:

• Create a new branch from the empty master.
• Name it as the specified project’s name.
• Add that project to that branch.
• Commit changes.

Quite number of steps but we can do easily though. However, what happens if we try cloning project by project to the workspace folder for working:

Workspace
|_ Project-A
|       |_ .git
|       |     |_ objects
|       |     |_ refs
|       |     |    |_ heads
|       |     |          |_ master
|       |     |          |_ Project-A
|       |     |          |_ Project-B
|       |     |
|       |     |_ config
|       |     |_ HEAD (content: refs: refs/heads/Project-A)
|       |
|       |_ README
|       |_ ...
|
|_ Project-B
|       |_ .git (HEAD: refs: refs/heads/Project-B)
|       |_ LICENSE
|       |_ ...
|_ ...

Opps! Each project now carries a whole structural of the original repository with it. The different is the HEAD of each repository refers to a specific *project’s name* branch whereas the HEAD of the original repository can point to any branch. I know if we specify local repository type in clone command (don’t remember exactly, though), git will create symbolic links to remote repository instead of replicating it over and over. Actually, my developing environment is mainly on Windows and we still have ability to create symbolic links (junction – sysinternal) but I doubt if msysgit could do the trick or I have to do it manually and… repository management explodes! No, I want a solution but I don’t need this ugly one!

Solution 2: Git Superproject

The superproject serves for another purposes but let’s see whether it can help. First off, I have to create our project repositories in somewhere (e.g workspace). After that, I go to the central repository and add those repositories as its sub-modules. It is now so called “super-project”.

Workspace
|_ Project-A
|       |_ .git
|       |_ README
|       |_ ...
|
|_ Project-B
|       |_ .git
|       |_ LICENSE
|       |_ ...
|_ ...

git submodule add /path/to/workspace/Project-A Project-A
git submodule add /path/to/workspace/Project-B Project-B

Repository
|_ .git
|_ .gitmodules
|_ Project-A
|       |_ .git
|       |_ README
|       |_ ...
|
|_ Project-B
|       |_ .git
|       |_ LICENSE
|       |_ ...
|_ ...

Well, if I commit some changes in the workspace projects’ repositories and I want them to be updated in my central repository, I have to go to that repository and do git pull for all sub modules (aha, cronjob script)… So it still introduces the same problem here: repository management explodes! This time, I even have to do more tedious works that git should be responsible for. Git superproject is absolutely not designed for doing this task!

Solution 3: Individual Project Repository – Yes, I named it!

Repository
|_ Project-A.git
|       |_ objects
|       |_ refs
|       |_ config
|       |_ ...
|_ Project-B.git
|       |_ objects
|       |_ refs
|       |_ config
|       |_ ...
|_ ...

The repository in this case is just a normal directory which contains a bunch of git repositories. Each repository is one of my projects. So, if I check out Project-A, or Project-B… one by one to my workspace folder, I will get this directory structure:

Workspace
|_ Project-A
|       |_ .git
|       |_ README
|       |_ ...
|
|_ Project-B
|       |_ .git
|       |_ LICENSE
|       |_ ...
|_ ...

Elegant & straight forward! One big disadvantage is we still cannot keep track of all changes from different projects in place although we can do it for individual project very well. If you had developed a similar type of project like an Eclipse RCP project which comprises of different plugins, and each plugin is an individual Java project, you would have wanted to see all those changes in the parent project rather than the plugin projects! This solution doesn’t achieve all my wants but I guess I should stick with it anyway. Of course, I will continue seeking for another way and it would be my pleasure to know your solution.

That’s said, git is not good enough for such kind of demand… but wait, git guys, I did choose git over svn because it’s cool, and it makes me cool ! Hopefully, as the time being, I can gain more experience in git and who knows, I will blame myself for such a stupid post

Um dos maiores problemas da sociedade moderna é a dificuldade de locomoção diária, a maioria das pessoas passa horas em seus carros, ou em meios de transporte públicos para irem de lugar a outro. Há alguns anos atrás quando morava na zona norte de São Paulo e trabalha na zona sul, essa era minha realidade. Uma vez que naquela época passar por isso era inevitável procurei formas de fazer com esse tempo pudesse de alguma forma torna-se produtivo, foi então que comecei a ouvir à podcasts.

iPod FM radio remote por dan taylor

De acordo com a Wikipedia, Podcasting é uma forma de publicação de arquivos de mídia digital (áudio, vídeo, foto, etc.) pela Internet, através de um feed RSS, que permite aos utilizadores acompanhar a sua atualização. Assim, é possível o acompanhamento e/ou download automático do conteúdo de um podcast.

Neste post apresentarei os podcasts aos quais escuto e os episódios principais para que você ouça. Sugiro que você utilize o iTunes para inscrever-se nos podcasts e sincronizar com seu iPod.

Desenvolvimento Ágil

por pcalcado

Podcast da ImproveIt

por Vinícius Teles
http://improveit.com.br/podcast
Português

• Entrevista com Alisson Vale da Phidelis
• Entrevista com Alexandre Magno na Série Experiências Ágeis
• Entrevista com Carlos Barbieri sobre o MPS.BR
• Entrevista com a equipe da Ancar na Série Experiências Ágeis

AgilCast

Por AgilCoop
http://agilcoop.incubadora.fapesp.br/portal/agilcast
Português

• Uma Visão Geral Sobre Scrum
• Testes Automatizados
• Bancos de dados ágeis e refatoração de bancos de dados

Agile Toolkit Podcast
http://agiletoolkit.libsyn.com
Inglês

• Tom Goulet – Cucumber, Ruby and the transition to Generalizing Specialist (2009)
• Jim Miller – The Product Owner Role and Business Alignmnet
• Tips and Advice – Retrospectives

ThoughtWorks Podcast

http://www.thoughtworks.com/what-we-say/podcasts.html
Inglês

Open Source

FLOSS Weekly

por Leo Laport, Jono Bacon e Randal Schwartz
Inglês

• Entrevista com Kent Beck sobre Extreme Programming (XP)
• Entrevista com Linus Torvalds, o criador do Linux e do Git
• Entrevista com David Heinemeier Hansson criador do Ruby On Rails
• Entrevista com Tim O’Reilly, fundador e CEO da  O’Reilly Media
• Entrevista com John Resig criador e líder do Projeto jQuery
• Entrevista com Jan Lehnardt evangelista do projeto CouchDB
• Entrevista com  Jacob Kaplan-Moss criador do Django
• Entrevista com Bruno Souza sobre o OpenJDK
• Entrevista com Ward Cunningham inventor do Wiki e grande Personalidade da Comunidade Ágil
• Entrevista com  D. Richard Hipp criador do SQLite
• Entrevista com Nate Koechley sobre o Yahoo User Interface Library (YUI)
• Entrevista com Junio Hamano, Mantenedor do Git
• Entrevista com Rasmus Lerdorf, criador do PHP
• Entrevista com Guido van Rossum, Criador do Python
• Entrevista com o fundador da Wikipedia, Jimmy Wales

Java

HorecaExpo - Java por bramloquet

JavaPosse

Por Tor Norbye, Carl Quinn, Dick Wall e Joe Nuxoll
Inglês
http://www.javaposse.com

Java Technology Insider

Inglês
http://www.javaworld.com/podcasts/jtech

• Rod Johnson: SpringSource and the future of Spring (2008)

Grails Podcast

Por Glen Smith e Sven Haiges
http://grailspodcast.com

Ruby

Ruby on Rails por Andrew*

Rails Envy

Por Jason Seifer e Gregg Pollack
Inglês
http://railsenvy.com

Rails Podcast

por Geoffrey Grosenbach
Inglês
http://podcast.rubyonrails.com/

• Entrevista com David Heinemeier Hansson (2005)
• Entrevista com Dave Thomas (2005)
• Entrevista com Chad Fowler (2005)
• Entrevista com Obie Fernandez (2006)
• Entrevista com Dave Thomas e Mike Clark (2006)

Rubiverse Podcast

Por Mike Moore
Ingles
http://rubiverse.com

• Dave Hoover on Software Crafsmanship (2009)
• Obie Fernandez on the Rails Maturity Model (2009)
• Ola Bini on Polyglot Programming (2008)

JavaScript

jQuery Podcast

Português
http://blog.jquery.com/2009/11/13/announcing-the-official-jquery-podcast/

Gadgets

GeekBrief TV

por Cali Lewis
Inglês
http://www.geekbrief.tv

Software

Desk por Guillermo Esteves

Pragmatic Podcasts

por Pragmatic Bookshelf
Inglês
http://www.pragprog.com/podcasts

• Chad Fowler on the Passionate Programmer
• Fred Daoud on Stripes
• Chad Fowler Finding the Jagged Edges
• Andy Hunt on Pragmatic Wetware

Software Engineering Radio

por Software Engineering Radio
http://www.se-radio.net
Inglês

• Software Archaelogy with Dame Thomas
• Fearless Change with Linda Rising
• Learning as a Part of Development with Allan Kelly
• SQL with Jim Melton
• Continuous Integration with Chris Read
• Top 10 Architecture Mistakes with Eoin Woods
• Usability with Joachim Machate
• Introduction to AOP with Christa Schwanninger e Iris Groher
• Retrospectives with Linda Rising
• 10 years of Agile Experiences
• Joe Armstrong on Erlang
• Interview Dave Thomas
• Dick Gabriel on Lisp
• Jeff DeLuca on Feature Driven Development
• Interview Erich Gamma
• Gerard Meszaros on XUnit Test Patterns
• Static Code Analysis with Jonathan Aldrich
• Refactoring Pt. 1
• Refactoring Pt. 2
• eXtreme Programming Pt.1
• eXtreme Programming Pt.2
• Agile Documentation
• Interview Jutta Eckstein
• Interview Eric Evans
• Patterns

Elegant Code

por Elegant Code Community
http://elegantcode.com
Inglês

• Agile for Families
• Entrevista com Jim Wierich o Criador do Rake (Ruby)
• David Laribee on Lean / Kanban
• Uncle Bob Martin on Clean Code
• Alan Shalloway on Lean
• Entrevista com Jarod Ferguson
• Entrevista com Darrel Carver
• Entrevista com Scott Nichols
• Entrevista com Scott Schimanski

Google Developer Podcast

http://code.google.com/p/google-developer-podcast/downloads/list
Inglês

Hearding Code

http://herdingcode.com
Inglês

Tecnologia

IT Conversations

http://itc.conversationsnetwork.org
Inglês

net@Night

por Amber MacArthur e Leo Laport
http://www.twit.tv/natn

Twit – This Week in Tech

por  Leo Laporte, Jeff Jarvis, Baratunde Thurston, e John C. Dvorak
http://www.twit.tv/twit

MacBreak Weekly

por Leo Laporte, Don McAllister, Paul Kent, and Andy Ihnatko
http://www.twit.tv/mbw

This Week in Google

por Leo Laporte, Gina Trapani, Jeff Jarvis e Mary Hodder
http://www.twit.tv/twig

SitePoint Podcast

inglês
http://www.sitepoint.com/podcast

Empreendedorismo e Negócios

37 Signals Podcast

por 37 Signals
Inglês
http://37signals.com/podcast

Max Gehringer (CBN)

por Max Gehringer
Português
http://cbn.globoradio.globo.com/servicos/podcast/NOME.htm

Mundo Corporativo (CBN)

por Heródoto Barbeiro
Português em Áudio
http://cbn.globoradio.globo.com/servicos/podcast/NOME.htm

The Startup Success Podcast

http://startuppodcast.wordpress.com
Inglês

TED Talks

por TED Talks
Inglês
http://www.ted.com

Se você quiser incluir algum outro podcast nesta lista, deixe um comentário. Espero que seja Útil!

The latest maintenance release GIT 1.6.5.3 is available at the
usual places:

http://www.kernel.org/pub/software/scm/git/

git-1.6.5.3.tar.{gz,bz2}                      (source tarball)
git-htmldocs-1.6.5.3.tar.{gz,bz2}             (preformatted docs)
git-manpages-1.6.5.3.tar.{gz,bz2}             (preformatted docs)

The RPM binary packages for a few architectures are found in:

RPMS/$arch/git-*-1.6.5.3-1.fc9.$arch.rpm      (RPM)

Git v1.6.5.3 Release Notes

Fixes since v1.6.5.2

• info/grafts file didn’t ignore trailing CR at the end of lines.

• Packages generated on newer FC were unreadable by older versions of
  RPM as the new default is to use stronger hash.

• output from “git blame” was unreadable when the file ended in an
  incomplete line.

• “git add -i/-p” didn’t handle deletion of empty files correctly.

• “git clone” takes up to two parameters, but did not complain when
  given more arguments than necessary and silently ignored them.

• “git cvsimport” did not read files given as command line arguments
  correctly when it is run from a subdirectory.

• “git diff –color-words -U0″ didn’t work correctly.

• The handling of blank lines at the end of file by “git diff/apply
  –whitespace” was inconsistent with the other kinds of errors.
  They are now colored, warned against, and fixed the same way as others.

• There was no way to allow blank lines at the end of file without
  allowing extra blanks at the end of lines. You can use blank-at-eof
  and blank-at-eol whitespace error class to specify them separately.
  The old trailing-space error class is now a short-hand to set both.

• “-p” option to “git format-patch” was supposed to suppress diffstat
  generation, but it was broken since 1.6.1.

• “git imap-send” did not compile cleanly with newer OpenSSL.

• “git help -a” outside of a git repository was broken.

• “git ls-files -i” was supposed to be inverse of “git ls-files” without -i
  with respect to exclude patterns, but it was broken since 1.6.5.2.

• “git ls-remote” outside of a git repository over http was broken.

• “git rebase -i” gave bogus error message when the command word was
  misspelled.

• “git receive-pack” that is run in response to “git push” did not run
  garbage collection nor update-server-info, but in larger hosting sites,
  these almost always need to be run. To help site administrators, the
  command now runs “gc –auto” and “u-s-i” by setting receive.autogc
  and receive.updateserverinfo configuration variables, respectively.

• Release notes spelled the package name with incorrect capitalization.

• “gitweb” did not escape non-ascii characters correctly in the URL.

• “gitweb” showed “patch” link even for merge commits.

• “gitweb” showed incorrect links for blob line numbers in pathinfo mode.

Other minor documentation updates are included.

Changes since v1.6.5.2 are as follows:

Björn Gustavsson (1):
      git-clone.txt: Fix grammar and formatting

Björn Steinbrink (1):
      pre-commit.sample: Diff against the empty tree when HEAD is invalid

Clemens Buchacher (1):
      modernize fetch/merge/pull examples

Daniel Barkalow (2):
      Require a struct remote in transport_get()
      Allow curl helper to work without a local repository

Dmitry V. Levin (1):
      Makefile: add compat/bswap.h to LIB_H

Gerrit Pape (1):
      help -i: properly error out if no info viewer can be found

Gisle Aas (2):
      More precise description of 'git describe --abbrev'
      Fix documentation grammar typo

Giuseppe Bilotta (1):
      gitweb: fix esc_param

Jakub Narebski (1):
      gitweb: Do not show 'patch' link for merge commits

Jan Krüger (1):
      rebase -i: more graceful handling of invalid commands

Jari Aalto (3):
      Documentation/fetch-options.txt: order options alphabetically
      Documentation/git-pull.txt: Add subtitles above included option files
      Documentation/merge-options.txt: order options in alphabetical groups

Jeff King (6):
      cvsimport: fix relative argument filenames
      push: always load default config
      add-interactive: handle deletion of empty files
      ls-files: unbreak "ls-files -i"
      push: fix typo in usage
      format-patch: make "-p" suppress diffstat

Johannes Schindelin (3):
      blame: make sure that the last line ends in an LF
      help -a: do not unnecessarily look for a repository
      diff --color-words -U0: fix the location of hunk headers

Jonathan Nieder (4):
      clone: detect extra arguments
      Add intermediate build products to .gitignore
      check-ref-format: update usage string
      merge: do not setup worktree twice

Junio C Hamano (22):
      apply --whitespace=fix: fix handling of blank lines at the eof
      apply --whitespace=fix: detect new blank lines at eof correctly
      apply.c: split check_whitespace() into two
      apply --whitespace=warn/error: diagnose blank at EOF
      apply --whitespace: warn blank but not necessarily empty lines at EOF
      diff.c: the builtin_diff() deals with only two-file comparison
      diff --whitespace=warn/error: obey blank-at-eof
      diff --whitespace=warn/error: fix blank-at-eof check
      diff --color: color blank-at-eof
      core.whitespace: split trailing-space into blank-at-{eol,eof}
      diff --whitespace: fix blank lines at end
      diff.c: shuffling code around
      diff.c: split emit_line() from the first char and the rest of the line
      diff.c: emit_add_line() takes only the rest of the line
      diff -B: colour whitespace errors
      info/grafts: allow trailing whitespaces at the end of line
      gc --auto --quiet: make the notice a bit less verboase
      receive-pack: run "gc --auto --quiet" and optionally "update-server-info"
      clone: fix help on options
      diff --color-words: bit of clean-up
      check-ref-format -h: it does not know the --print option yet
      Git 1.6.5.3

Markus Heidelberg (1):
      t4034-diff-words: add a test for word diff without context

Petr Baudis (1):
      gitweb: Fix blob linenr links in pathinfo mode

Sebastian Schuberth (1):
      Do not try to remove directories when removing old links

Stephen Boyd (1):
      git-add.txt: fix formatting of --patch section

Thomas Rast (1):
      Quote ' as \(aq in manpages

Todd Zullinger (1):
      Makefile: Ensure rpm packages can be read by older rpm versions

Vietor Liu (1):
      imap-send.c: fix compiler warnings for OpenSSL 1.0

Before I start, an announcement that should make any electronics enthusiast explode with joy.
Any person who has dealt with a computer related project would tell you how incredibly helpful and *indispensable* the parallel port can be. It has this great reputation due to the fact that it’s is extremely easy to deal with both in circuits (IO lines can be connected directly to 74{LS}* – TTL compatible) and programming.
The trusty parallel, however, has been in a recession ever since the USB came out. Today, it’s difficult to find a PC motherboard with an parallel port, and you can definitely forget about laptops with the PP.

Many USB solutions exist, but nearly none are as practical and universal as the good-old PP. and until recently, my only option was my old Compaq Armada PP2060.

It turns out that FTDI (link) manufactures usb-serial converters which can be operated in bit-bang mode! this means that you can get up to 8 general purpose I/O lines. The main selling points for me was that it’s 3.95$ (link), there is a breakout board (link), and most importantly, there is a library for it for linux!
expect a detailed tutorial in the near future

Now on to whats been happening this past week:

git

The comes a point in every programmer’s life when he/she realizes that he/she needs some sort of source code management. I was no exception. So I started looking for scm software. while searching, I came across git. I read a little about it and had the false assumption that it’s main feature was that Torvalds wrote it, which is not much of a reason for anything. so I decided on svn. recently, I came across a youtube video in which Linus talked about git (link). It opened my eyes on several issues with svn that i wasn’t aware of. he also mentioned some of the futures that got me searching for a SCM system in the first place. It seems that i might be switching to git soon! of course, that is if I ever get around to actually learning it never mind, switched already
for more information, see the video (link) and vist git (link).

Google Wave

Wave is interesting to say the least. a couple of days ago, I was invited by anxious.nut to google wave. To be honest, a did not expect this. after all, I wasn’t invited to gmail when it was invitation only -even though one person offered to invite me verbally, and I certainly didn’t do anything to get invited to this one. but i guess it helps to know a hardcore geek.
Anyways, The interface is designed in a simplistic manner; you get for boxes for wave lists, and for the wave itself. plus two more for contacts and navigation. Waves can be edited simultaneously (like google docs) and can be viewed at deferent point in its history (can single-step from the wave’s start up to its current state). I suppose it has its uses.
Anyways, being who we are (myself, and Anxious), we decided to test if it could be used for programming (you know, real time collaboration). suffice to say, it’s not for code development. it would of been fun if more people joined in though. my googlewave id is SIGTERMer [at] googlewave [dot] com.

A Pleasant Surprise…

It turns out that we have a close ubuntu repository here in Kuwait! It’s provided by qualtynet (link) and is synced every 4 hours. I haven’t switch repos yet but if it’s faster, and everything checks out, I will.
Thanks Qualtynet

link dump

Last but not least, some of the more interesting sites I’ve stumbled across this week
- Dirty Coding Tricks (link)

Until next time,
SIGTERMer

SmartGit 1 Milestone 7b2 (2009-11-17) syntevo GmbH (독일)

SmartSVN 제작사에서 내놓은 JGit 기반의 Git 클라이언트. GitHub 지원.

Git 바이너리는 따로 설치해야 한다. 추천하는 패키지는 http://code.google.com/p/git-osx-installer. /usr/local/git에 설치된다.

요즘은 Git이 대세인 듯.

When doing a git clone from a repo hosted on a Mac OSX machine (installed using macports), I get this error on the client (Linux, cygwin, whatever):

git-upload-pack: command not found

Solution is to do this on the OSX machine:

cd /usr/bin
sudo ln -s /opt/local/bin/git* .

Obviously some $PATH funkiness is going on somewhere on the Mac, and I should find a better fix. My personal $PATH on the Mac is OK:

$ echo $PATH
/opt/local/bin:/opt/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin

ben olmayınca hemen bulmuşsun birini
yol ayrımında unuttun yeminlerini
sen bitirdin hem kendini hem de beni
şimdi git artık, dönme geri

bir gün aşklar biter, hatıralar kalır,
kimi seversen sev hep hatırlatır
sanma bir başkası yerimi alır
gelenler gideni elbet aratır

I have been wanting to learn more about Git Submodules and how they work, so I watched the screen cast at the bottom of http://book.git-scm.com/5_submodules.html (would have embedded it, but there were issues doing so). The bottom line is that the Super module contains a reference to a specific version of a Sub module. Git’s submodule command can then determine if you have a different version of the Sub than you should, it can fetch the current version, etc.

The process sort of goes like this, using C1 for Computer 1 and C2 for Computer 2:

1. C1: change Submodule
2. C1: commit Super module, freezing version of Sub used by Super
3. C1: push Super module
4. C2: pull Super module, gets the updated Sub module version SHA
5. C2: submodule update, gets the updated Sub code corresponding to the version in #4.

Some observations:

• Will a user ever do 4 and NOT do 5? Why?
• If 4 and 5 are tied together, why is that not one step (ala git push = git fetch; git merge origin/master)?
• C2 has no idea to update the Sub code unless they are carefully watching the pull output or run git submodule status directly after 4 above to know that a Sub update is needed
• Possible source of issues if C2 has Version x+1 of Super but only version x of Sub

Now, I’m new to Git, but it would seem to me that one could write a hook that would automatically run git submodule update if .gitmodules is present in the directory. It would seem that an appropriate hook to git pull would be to add git submodule update after the pull. Am I missing something here?

I understand that git’s submodule support has been added-on as submodules were not something in the design of Git. I wonder if the lack of these hooks and a better user experience is the direct side effect of that bolt-on?

Mercurial seems to be trying to do this via it’s subrepos support:

Whenever newer Mercurial versions encounter this .hgsubstate file when updating your working directory, they’ll attempt to pull the specified subrepos and update them to the appropriate state.

Enough to make me switch? Not if I can write a hook.

git is too complicated for me. It’s supposed to be awesome, but I just can’t figure it out.

I have 3 Debian laptops which I use daily. One at home, one at school, and one which I carry in my backpack. I’m also a backup nut. I have 4 external drives totaling 3.25T of storage which are for storing and backing each other up. For years I used rsync with linked files, which was alright but always had issues — sometimes the links wouldn’t propagate back properly for no apparent reason. I’d have the impression that things were working well when … really there was just the latest snapshot available.

Recently I’ve switched to unison for backing up things like photos and videos, which works great and has a nice GUI. It makes snapshots and just synchronizes the drives, with minimal muss and fuss.

But for my daily work, I want something with some history, like I had hoped to get from rsync, so I can revert a file to its previous state. I wanted something which wouldn’t have a ‘main’ copy and then child copies but rather where each laptop could function stand-alone and then quickly synchronize with the others whenever they were available. I wanted something which could run over ssh. I suspected git might do some of it, but I am surprised now how much of what I wanted, git does, and does well.

So I tried out git for while, but git has a steep learning curve. So steep that its the kind of thing which I abandon if I don’t get traction quickly, since I have little time to learn technical tools like this, especially tools which are not documented for beginners. (I’ve had that issue with OpenBSD, which seems like a nice OS, and which I’ve installed, but I’ve run into issues within the first day and then had to reformat over with Debian testing.)

However git has something which is an absolutely remarkable solution to this problem. There is an excellent, friendly git IRC channel at irc.freenode.net/#git. Several people there have given me such valuable advice specific to my situations that came up in the beginning that I’ve learned git to the point where it’s a tool that helps me so much I can’t do without it. There’s lots of primers and introductions out there, but I didn’t find one that really cut it for me; it is sorely needed, but the IRC channel makes up for its absence.

One key piece of advice I got was to avoid git push and pull in the beginning, and rather use git fetch and merge only. This was good advice, since you get a better sense of what each piece is doing, and it works.

So I wrote a couple of bash scripts which I use everyday and which I like. First I have in my .bashrc a line like

export GITDIRS=~/proj1:~/proj2:~/proj3

Whenever I need to sync up laptops I run the following bash script I call gitac (for git-add commit):

#!/bin/bash

IFS=:
for gitdir in $GITDIRS; do
    echo $gitdir
    pushd $gitdir
    git add .
    git commit
    popd
done

and then I ssh to the target laptop and run gitfr (for gitfrom):

#!/bin/bash

IFS=: 

for gitdir in $GITDIRS; do
    echo $gitdir
    pushd $gitdir
    git fetch $1:$gitdir HEAD
    git merge FETCH_HEAD
    popd
done

These work superfast and sync my laptops better than I could’ve asked for from rsync. I can see the commits graphically using gitk which is nice.

When I’m syncing my laptops it isn’t always a sensible time to do a significant commit on all my projects, but with git you can have several branches, one for daily working commits and another for significant commits — I’ve yet to completely work that out and also find out how to propagate such branch information. git is flexible about how you use it, and if it works, then it works. Another thing I like is that none of the machines is “central”; in fact, I view them all as backing each other up. In particular, I don’t need the external drives for backing up my daily work anymore, they’re only for photos, videos, and things like that.

The only obvious issue is if I edit the same file on 2 different laptops and then sync, then I get merge conflicts, as would be expected. At first this was a problem, but now I generally remember to start a work session by gitfr from my backpack laptop to keep everything sync’d up.

Abordarei a criação de um repositório Git remoto usando o SSH num ambiente Linux.

Não incluirei detalhes da configuração do SSH.

É necessário que os seguintes pacotes estejam instalados: git e ssh.

Primeiro configure o SSH editando o arquivo /etc/ssh/sshd_config.

Eu recomendo algumas configurações[1]:

Protocol 2    # Permite apenas a versão 2 do protocolo (mais seguro)
PermitRootLogin no    # Não permite login como root
PasswordAuthentication no    # Não permite login por senha

Agora é necessário criar um usuário para acesso ao Git através do SSH.

Eu recomendo que o nome do usuário seja git e que seja criado com o seguinte comando[2]:

useradd -r -m --shell /usr/bin/git-shell git

Definindo o shell do usuário para /usr/bin/git-shell o acesso do usuário será restrito aos comandos do Git[3].

O diretório pessoal do usuário git será criado em /home/git.

Se você não tem uma chave para o SSH, crie-a com o comando ssh-keygen (usando seu usuário).

Será criada uma chave pública e privada em ~/.ssh, a chave pública tem o sufixo .pub (nunca compartilhe sua chave privada).

Agora é necessário adicionar sua chave pública a lista de chaves autorizadas do usuário git, para isso faça o seguinte:

mkdir /home/git/.ssh

cat /home/seu_usuario/.ssh/id_rsa.pub >> /home/git/.ssh/authorized_keys

Supondo que o nome de sua chave pública seja id_rsa.pub.

Agora será necessário criar um repositório no diretório pessoal do usuário git.

Para criar um repositório para o projeto ProjetoTeste, faça o seguinte:

mkdir /home/git/ProjetoTeste

cd /home/git/ProjetoTeste

git init --bare

Agora é necessário garantir que tudo pertença ao usuário git, faça o seguinte:

cd /home/git
chown -R git.git .    # não esqueça do ponto no final

Isso é tudo.

Para clonar o repositório use o seguinte comando:

git clone git@ip_do_servidor:ProjetoTeste

Referência:

1- http://linux.die.net/man/5/sshd_config ou man 5 sshd_config.

2- http://linux.die.net/man/8/useradd ou man 8 useradd.

3- http://linux.die.net/man/1/git-shell ou man 1 git-shell.

özledim seni…

ayrılık yüreğimi uyuşturuyor karıncalandırıyor nicedir.
beynimi uyuşturuyor özlemin…
çok sık birlikte olmasak bile
benimle olduğunu bilmenin
bunca zamandır içimi ısıttığını
yeni yeni anlıyorum
Yokluğun,
Hatırladıkça yüreğime saplanan bir sızı olmaktan çıkıp
mütemadiyen bir boşluğa
Sabahları seni okşayarak başlamaları
aksamları her isi bir kenara koyup
seninle baş başa konuşmaları özlüyorum;
oynaşmalarımızı,
yürüyüşlerimizi,
sevimli haşarılığını,
çocuksu küskünlüğünü…
Nasılda serttin başkalarına karşı
beni savunurken;
ve ne kadar yumuşak
bir çift kısık gözle kendini
ellerimin okşayışına bırakırken
Gitmeni asla istemediğim halde
buna mecbur olduğunu görmek
ve sana bunları söylemeden
”git artık” demek
”beni ne kadar çabuk unutursan, o kadar çabuk
kavuşacaksın mutluluğa”
demek sana nede zor
seni görmemek ve belki yıllar sonra
karsılaştığımızda
bana bir yabancı gibi bakmanı istemek senden…
yeni bir sevdayı yasakladığım kalbime söz geçirmek….

Can YÜCEL

Index

1. Background
2. Converting Subversion to Git
   • svn2git.sh
3. Generate and version .gitignore files
   • exclude2gitignore.sh
4. Git via proxy
5. Setting up pull everywhere
6. References

Background

I’ve got a desktop and server behind a router with a dynamic IP address at home, a desktop at work, and a laptop that floats around. I’d very much like to have the same settings on all of them, and to be able to synchronize them as easily as possible. I’ve been using Subversion for this, but recent trouble with symlinks and a long-term concern that storing the revision history centrally (even with backups now and then) is a Bad Move in the long term. So when I had to start using Git at work, and after realizing that it could solve both problems (at least in theory), I tried figuring out how to do this. After lots of tries followed by rm -rf settings/, I think I’ve got a working setup. Of course, I don’t guarantee that any of this will work for you.

Converting Subversion to Git

Install the necessary software:
sudo apt-get install git-svn

Copy the following code into a file named svn2git.sh, and run it as documented below.

svn2git.sh

#!/bin/sh
#
# NAME
#    svn2git.sh - Convert a Subversion repository to Git
#
# SYNOPSIS
#    svn2git.sh [options] <Subversion URL>
#
# OPTIONS
#    --authors=path  Authors file
#    -v,--verbose    Verbose output
#
# EXAMPLE
#    /path/to/svn2git.sh https://example.org/foo
#
#    Create authors file for repository
#
#    /path/to/svn2git.sh -v --authors=authors.txt https://example.org/foo
#
#    Get Subversion repository to ./foo.git
#
# DESCRIPTION
#    Two-part script to migrate from Subversion to Git. First it tries to get
#    a list of the Subversion authors, so it can be formatted to fit the Git
#    commit structure. When running with the authors file, it will fetch the
#    entire Subversion revision history.
#
# BUGS
#    Email bugs to victor dot engmark at gmail dot com. Please include the
#    output of running this script in verbose mode (-v).
#
# COPYRIGHT AND LICENSE
#    Copyright (C) 2009 Victor Engmark
#
#    This program is free software: you can redistribute it and/or modify
#    it under the terms of the GNU General Public License as published by
#    the Free Software Foundation, either version 3 of the License, or
#    (at your option) any later version.
#
#    This program is distributed in the hope that it will be useful,
#    but WITHOUT ANY WARRANTY; without even the implied warranty of
#    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
#    GNU General Public License for more details.
#
#    You should have received a copy of the GNU General Public License
#    along with this program.  If not, see <http://www.gnu.org/licenses/>.
#
################################################################################

# Output error message with optional error code
error()
{
    if [ -z "$2" ]
    then
        error_code=$EX_UNKNOWN
    else
        error_code=$2
    fi
    echo "$1" >&2
    exit $error_code
}

usage()
{
    error "Usage: ${cmdname} [-v|--verbose] [--authors=path] <Subversion URL>" $EX_USAGE
}

verbose_echo()
{
    if [ $verbose ]
    then
        echo "$*"
    fi
}

# Use for mandatory directory checks
# $1 is the directory path
# $2 is the (optional) error message
directory_exists()
{
    if [ ! -d $1 ]
    then
        error "No such directory '${1}'
$2" $EX_NO_SUCH_DIR
    fi
}

# Make sure an executable is available
# $1 is the path to the executable
# $2 is the (optional) error message
executable_exists()
{
    if [ ! -x $1 ]
    then
        error "No such executable '${1}'
$2" $EX_NO_SUCH_EXEC
    fi
}

PATH="/usr/bin:/bin"
cmdname=`basename $0`
directory=$PWD

# Exit codes from /usr/include/sysexits.h, as recommended by
# http://www.faqs.org/docs/abs/HTML/exitcodes.html
EX_OK=0           # successful termination
EX_USAGE=64       # command line usage error
EX_DATAERR=65     # data format error
EX_NOINPUT=66     # cannot open input
EX_NOUSER=67      # addressee unknown
EX_NOHOST=68      # host name unknown
EX_UNAVAILABLE=69 # service unavailable
EX_SOFTWARE=70    # internal software error
EX_OSERR=71       # system error (e.g., can't fork)
EX_OSFILE=72      # critical OS file missing
EX_CANTCREAT=73   # can't create (user) output file
EX_IOERR=74       # input/output error
EX_TEMPFAIL=75    # temp failure; user is invited to retry
EX_PROTOCOL=76    # remote error in protocol
EX_NOPERM=77      # permission denied
EX_CONFIG=78      # configuration error

# Custom errors
EX_UNKNOWN=1
EX_NO_SUCH_DIR=91
EX_NO_SUCH_EXEC=92

# Process parameters
until [ $# -eq 0 ]
do
    case $1 in
        -v|--verbose)
            verbose=1
            shift
            ;;
        --authors=*)
            authors_file=${directory}/$(echo "$1" | cut -c11-)
            shift
            ;;
        *)
            if [ -z $svn_url ]
            then
                svn_url=$1
                shift
            else
                # Unknown parameter
                usage
            fi
            ;;
    esac
done

if [ -z $svn_url ]
then
    # No Subversion URL provided
    usage
fi

repository_name=`basename $svn_url`

verbose_echo "Running $cmdname at `date`."

# Preliminary checks
directory_exists "$source_base"
executable_exists "/usr/bin/git"
executable_exists "/usr/bin/git-svn"
executable_exists "/usr/bin/svn"

verbose_echo "Source repository: '${svn_url}'"

if [ -z $authors_file ]
then
    # Get authors file
    authors_file="${directory}/${repository_name}-authors.txt"
    if [ -e $authors_file ]
    then
        error "Authors file '${authors_file}' already exists"
    fi
    verbose_echo "Authors file: ${authors_file}"

    svn log --quiet "${svn_url}" | grep '^r.*' | cut -d ' ' -f 3- | cut -d '|' -f 1 | sort | uniq > "${authors_file}"

    author="$(head -1 $authors_file)"
    echo "Please modify ${authors_file} to a format like"
    echo "${author}= Full Name <${author}@example.org>"
    echo "and rerun $cmdname with --authors=${authors_file}"
else
    if [ ! -e $authors_file ]
    then
        error "Authors file '${authors_file}' doesn't exist"
    fi

    git_target="${directory}/${repository_name}.git"
    if [ -e $git_target ]
    then
        error "Target repository '${git_target}' already exists"
    fi
    verbose_echo "Target repository: '${git_target}'"

    # Clone
    git-svn clone --no-metadata --authors-file="${authors_file}" --revision 1:1 "$svn_url" "$git_target" || error "Clone failed"

    # Fetch
    cd "$git_target"
    batch_start=2
    revisions=$(svn info "$svn_url" | grep '^Revision:' | awk '{print $2}')
    while [ $batch_start -le $revisions ]
    do
        batch_end=$(expr $batch_start + 990)
        if [ $batch_end -gt $revisions ]
        then
            batch_end=$revisions
        fi

        verbose_echo "Fetching revisions $batch_start through $batch_end"
        git-svn fetch --authors-file="${authors_file}" --revision $batch_start:$batch_end || error "Fetch failed"

        batch_start=$(expr $batch_end + 1)
    done

    git rebase git-svn

    verbose_echo "Applying svn:ignore properties"
    git-svn show-ignore >> .git/info/exclude

    verbose_echo "Removing references to Subversion"
    git config --remove-section svn-remote.svn
    rm --recursive --force .git/svn/
fi

verbose_echo "Cleaning up."
cd "$directory"

verbose_echo "${cmdname} completed at `date`."
exit $EX_OK

Now make sure you do a directory diff between the old Subversion and the new Git repositories to see if it succeeded.

Now you can get this on other machines using
git clone --origin example ssh://example.org/~/settings

Generate and version .gitignore files

This is an optional step in case you would like to version the old svn:ignore properties as .gitignore files:

exclude2gitignore.sh

#!/bin/sh
#
# NAME
#    exclude2gitignore.sh - Convert $GIT_DIR/info/exclude to corresponding
#    .gitignore files
#
# SYNOPSIS
#    exclude2gitignore.sh [options] /path/to/repository
#
# OPTIONS
#    -v,--verbose    Verbose output
#
# EXAMPLE
#    /path/to/exclude2gitignore.sh ~/foo
#
#    Create .gitignore files for the Git repository in ~/foo
#
# DESCRIPTION
#    Based on the format generated by `git-svn show-ignore`, where non-comment
#    lines indicate ignored files. Will try to put the .gitignore as close as
#    possible to the ignored file(s).
#
# BUGS
#    Email bugs to victor dot engmark at gmail dot com. Please include the
#    output of running this script in verbose mode (-v).
#
# COPYRIGHT AND LICENSE
#    Copyright (C) 2009 Victor Engmark
#
#    This program is free software: you can redistribute it and/or modify
#    it under the terms of the GNU General Public License as published by
#    the Free Software Foundation, either version 3 of the License, or
#    (at your option) any later version.
#
#    This program is distributed in the hope that it will be useful,
#    but WITHOUT ANY WARRANTY; without even the implied warranty of
#    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
#    GNU General Public License for more details.
#
#    You should have received a copy of the GNU General Public License
#    along with this program.  If not, see <http://www.gnu.org/licenses/>.
#
################################################################################

# Output error message with optional error code
error()
{
    if [ -z "$2" ]
    then
        error_code=$EX_UNKNOWN
    else
        error_code=$2
    fi
    echo "$1" >&2
    exit $error_code
}

usage()
{
    error "Usage: ${cmdname} [-v|--verbose] /path/to/repository" $EX_USAGE
}

verbose_echo()
{
    if [ $verbose ]
    then
        echo "$*"
    fi
}

# Use for mandatory directory checks
# $1 is the directory path
# $2 is the (optional) error message
directory_exists()
{
    if [ ! -d $1 ]
    then
        error "No such directory '${1}'
$2" $EX_NO_SUCH_DIR
    fi
}

# Make sure an executable is available
# $1 is the path to the executable
# $2 is the (optional) error message
executable_exists()
{
    if [ ! -x $1 ]
    then
        error "No such executable '${1}'
$2" $EX_NO_SUCH_EXEC
    fi
}

PATH="/usr/bin:/bin"
cmdname=`basename $0`
directory=$PWD

# Exit codes from /usr/include/sysexits.h, as recommended by
# http://www.faqs.org/docs/abs/HTML/exitcodes.html
EX_OK=0           # successful termination
EX_USAGE=64       # command line usage error
EX_DATAERR=65     # data format error
EX_NOINPUT=66     # cannot open input
EX_NOUSER=67      # addressee unknown
EX_NOHOST=68      # host name unknown
EX_UNAVAILABLE=69 # service unavailable
EX_SOFTWARE=70    # internal software error
EX_OSERR=71       # system error (e.g., can't fork)
EX_OSFILE=72      # critical OS file missing
EX_CANTCREAT=73   # can't create (user) output file
EX_IOERR=74       # input/output error
EX_TEMPFAIL=75    # temp failure; user is invited to retry
EX_PROTOCOL=76    # remote error in protocol
EX_NOPERM=77      # permission denied
EX_CONFIG=78      # configuration error

# Custom errors
EX_UNKNOWN=1
EX_NO_SUCH_DIR=91
EX_NO_SUCH_EXEC=92

# Process parameters
until [ $# -eq 0 ]
do
    case $1 in
        -v|--verbose)
            verbose=1
            shift
            ;;
        *)
            if [ -z $repository ]
            then
                repository="${1%\/}"
                shift
            else
                # Unknown parameter
                usage
            fi
            ;;
   esac
done

verbose_echo "Running $cmdname at `date`."

directory_exists "$repository"

grep '^/' "${repository}/.git/info/exclude" | while read line
do
    ignore_path="${repository}${line}"
    verbose_echo "Starting with $ignore_path"
    ignore_name="$ignore_path"

    # Strip globs in path
    ignore_path=`dirname "$ignore_path"`
    while [ ! -e "$ignore_path" ]
    do
        ignore_path=`dirname "$ignore_path"`
    done

    # Remove path from file name (need +2 to include the end slash and to
    # compensate for 1-based indexing
    name_length=$(expr length "$ignore_name")
    path_length=$(expr length "$ignore_path" + 2)
    ignore_name=$(expr substr "$ignore_name" $path_length $name_length)

    # Complete .gitignore path
    ignore_path="${ignore_path}/.gitignore"

    verbose_echo "$ignore_name >> $ignore_path"
    echo "$ignore_name" >> "$ignore_path"
done

verbose_echo "Cleaning up."
cd "$directory"

verbose_echo "${cmdname} completed at `date`."
exit $EX_OK

Git via proxy

One of the machines involved is behind a gateway machine at work, so I had to add the following to ~/.ssh/config:

Host work
     ProxyCommand ssh -q gateway.example.org nc %h %p $*
     HostName work-pc.example.org

With this, it’s possible to refer to just “work”, and SSH commands (even via Git) will take care of connecting via the proxy.

Setting up pull everywhere

The main idea here is to set up Git “remotes” pointing to all the other machines.

To be able to get the updates from the repository in ~/settings on my.example.org, simply run the following on all machines (except, of course, the home machine):
git remote add home ssh://home-pc.example.net/~/settings

To be able to get the updates from the “work” host specified with a proxy above, just use “work” for the host name:
git remote add work ssh://work/~/settings

To be able to pull from a machine which changes IP address, you could set up a DynDNS account and use one of their recommended update scripts to be able to refer to your machine using a single DNS name.

After cloning one of the copies on all of your hosts, you should be able to the following to get all the changes from the repositories:
git remote update && git pull
If this doesn’t work, you might have more luck fetching each repository individually, and then rebasing to it:
git fetch home && git rebase home/master

To keep a backup on a separate machine, just do a
git clone --origin example ssh://example.org/~/settings
there and set up pushing defaults on the other machines using
git config push.default matching
git remote add backup ssh://backup.example.org/~/settings
Then you can just git push backup master to backup the local master branch.

References

• How to convert from Subversion to Git
• git-svn manual page
• Git – SVN Crash Course
• GitFaq
• Excellent respondents at Stack Overflow (1, 2) and the Git community (1)
• Moving from subversion to git permanently – take 2
• $ cheat gitsvn

Also available as Gist

Ever wondered how much who adds/removes, its time to find out
(those are real stats, I just obfuscated the names )

Results

Git scores (in LOC):
mr-add              :  +482273       -9466
justu               :  +286250       -159905
grosser             :  +152384       -323344
another             :  +121257       -82116
naames              :  +104577       -13591
justfor             :  +68716        -72446
example             :  +7795         -4987
andeven             :  +5100         -1730
morenow             :  +4225         -2764
finish              :  +17           -19

Install
Copy init git_stats.rb and ruby git_stats.rb
(you can add the names of people who commit with different users into the ’same’ array)

# please add enhancements to http://gist.github.com/234560
#!/usr/bin/env ruby
t = Time.now

same = [['name-a','name-b'],['mr fred','fred']]
pipe = open("|git log --shortstat")
author = "unknown"
stats = {}

loop do
  line = pipe.readline rescue break
  author = $1 if line =~ /Author\: ([a-z]+) </
  found = same.detect{|a| a.include?(author)}
  author = found.first if found

  if line =~  /files changed, (\d+) insertions\(\+\), (\d+) deletions/
    stats[author] ||= Hash.new(0)
    stats[author]['+']+=$1.to_i
    stats[author]['-']+=$2.to_i
    print '.'
  end
end

puts "\nGit scores (in LOC):"
puts stats.sort_by{|a,d| -d['+'] }.map{|author, data| "#{author.ljust(20)}:  +#{data['+'].to_s.ljust(10)}   -#{data['-'].to_s.ljust(10)} " } * "\n"

Nací en respuesta a un concurso de innovación.
Les dejo un video que explica por qué estoy en el mundo.
Espero les guste!

Scytale entwickelt unter dem Namen “Levitation”. eine Alternative zu MediaWiki. Ist das eine geeignete Alternative für Wikipedia.

Die Sache funktioniert nur, wenn man auch ohne den Download irgendwelcher Daten mitmachen kann. Wenn durch eine solche Maßnahme die Eintrittschwelle erhöht wird, bleibt der Kreis der Autoren naturgegen klein und wird sich in der Regel wieder auf das altebekannte Spektrum (weiß, jung, computer- & netzaffin) stützen. Damit ist keine allgemeine Enzyklopädie machbar, eher ein Nerdlexikon. Es ist also der Aufbau einer Serverfarm erforderlich. Hierbei ist vor allem auf die Performance zu achten. Derzeit hat die deutsche Wikipedia ca. 700.000 Edits im Monat (ca. 23.000 am Tag, 16 Edits in der Minute). Zu Hochzeiten sind das auch schon mal 40-50 Edits. Die englische WP hat 4.000.000 Edits im Monat (1,5 Edits je Sekunde).

Außerdem scheint in diesem System die Mitwirkung von nicht angemeldeten Benutzern unmöglich zu sein. Damit würde ein wichtiger Teil der Benutzer unwiederbringlich wegfallen.

Soweit die technischen Aspekte. Wie sieht es mit der Manipulierbarkeit aus. Bisher werden vor allem kontroverse Artikel von vielen Benutzer beobachtet und auf einem Stand gehalten, der von der Mehrheit akzeptiert wird. In Zukunft kann eine Gruppe von Personen eine Artikelversion puschen, die ihren Vorstellungen entspricht. In diesem System brauch’ man nur genügend Accounts um eine entsprechende Manipulation zu erreichen. Die Sockenpuppenproblematik wird dann noch gefährlicher. Auch wird in diesem System die Meritokratie noch mehr gefördert. Ein Neuling hat nicht viele oder keine “Followers” und hat es demgegenüber schwer in einer vorhanden Gruppe akzeptiert zu werden. Insofern ist das System sogar wesentlich anfälliger für den Ausschluss bestimmter Personen von der Akzeptanz ihrer Arbeit.

Die Idee die dahinter steht ist an und für sich nicht schlecht, ob sie jedoch für den Einsatz zum Schreiben einer Enzyklopädie eignet, ist in meinen Augen nicht abschließend geklärt.

Git is a tool used extensively for open source projects.  It is a way of distributing source control instead of the typical central repository.  History has it that Linus Torvalds himself developed the original tool.

Every Git working directory is a full-fledged repository with complete history and full revision tracking capabilities, not dependent on network access or a central server.

Why is it called git?  The theory is that Linus named it after himself.  However, no one seems to know for sure.

Why git?  It all started as a dispute between the Linux developers and BitKeeper.  The BitKeeper tools had been free to the community until the company charged the developers with reverse engineering their product.   The result was that developers would need to pay to continue using BitKeeper.  Given the “free” nature of Linux development this obviously did not go down well.  Linus led the project to develop an alternative and the result is git.

The overall good news is that git has been widely adopted even though it was only created starting in 2005.  There are several good features it has compared to the traditional source control solutions.

• Offline changes
• Free (always helps)
• Fairly simple commands
• Distributed source management
• Open source (for the hardcore)

To get a better introduction, visit the git homepage.  As a set of examples of this homepage:

There is also a section on quick start.  Git has two paths for creating a repository.  Either it is created from a clone from another server or it is created from scratch.

Anything in parentheses is meant to be replaced with specific actions (like a directory or file).  To keep it simple, it is best to experiment with a locally created depot.  It is worth doing an easy walk through of the creation.

1. git init
2. git add .
3. git commit -m “My message”

“git init” creates the initial depot for this current project.  It creates a subdirectory (usually hidden) called .git which contains all the information that git needs to keep to manage the source.  Think of it as being where everything is kept to keep git happy.

“git add .” instructs git to find every single file under the current directory and add it to the staging area to be prepared for committing. It will only add files that are new or changed when used with the “.” which is a great trick.  If there are files that you do not want to automatically add, you can always change the “.gitignore” file to skip over them.  Typically the object and binaries need to be skipped if the tree is actually built.  Doing the add is really just a sign of intent.  It does not actually change anything in the git tree.  Also of note, if you change any files that have been added, you need to add them again if you want to capture the changes in the staging area.

There is nothing to fear with commitment.  Commit with “git commit” just means that you want to capture all the changes into one thing.  This is where it updates the local git tree and it is seen as a kind of “snapshot” of where the code is at.  Keep in mind that a commit means nothing to anyone else.  A commit is just a local thing.  This enables git to be used offline and without the need for a central server ever.

However, git can also be used in a distributed team.  In fact, that was the original intent.  That is the point of the other path for creating a depot on the local machine.

Working off of a remote depot is in this order:

1. clone a remote depot (git clone)
2. make changes to the local files (git add)
3. commit the changes (git commit)
4. send the patch to someone that cares (git format-patch)

This is not the only way to do it.  It is also possible to submit the changes back to the remote depot assuming you have been authorized.

Coming from a world of PVCS and Perforce, git can take some getting used to.  It seems uncommon for git to be used in commercial products in Citrix (except for Xen products).  XenApp and XenDesktop are based on Perforce.

There are so many different places you can go to find out more about git.  Here are some examples:

• Gitcasts – collection of videos about git features
• Pro Git – online book about git
• Git from the bottom up – understanding the internals
• Official git documentation site

Linus Torvalds (git creator) speaks about git at Google Talks.

Thanks goes to Michael Wookey in Citrix Labs Sydney for being such a great git advocate.

(scytale.name) – The last three days I have worked like crazy on a new project, and I’m happy to release its first usable version to the public now. The software is called Levitation and its purpose is to convert a MediaWiki database XML dump into a Git repository — including the complete history. …

http://scytale.name/blog/2009/11/announcing-levitation