Tag: git

Last Subversion repository decommissioned – at last!

Posted by – 01/10/2015

Today I completed the git migration of the last Subversion repository we still had online at Propus.

Nothing different from what we had done for all the rest, but this was an old repository, mostly with unmaintained code, modeled after “project-as-subdirectory” style… Good old days…

Two scripts – I am sure people can find somewhere else on the Internet – are worth pasting here:

First, I detected 3 revisions committed by root user. The first two matched the creation of first two projects (AKA directories), so I mapped the three of them to the same person (who had this bad habit of logging as root). It ended up I was wrong for the third revision: it was the beginning of a new project, but by a different person. Since the authors file maps one-to-one, “root” could only be one and the person.

So, after the migration, I just use filter-branch to fix that particular commit. Trivial, but worth a gist:

Lastly, there are some projects (mapped as subdirectories in the new git repo), that we’d like to split from the “archived” do keep using or adding to them. They will become active projects again. So, we cloned the whole repo again, and used filter-branch to the rescue:

Since that was the last Subversion repository still alive, I’d like to end this post with a thanks for all the years of good service! Time to move on…

Migrating from Mephisto to WordPress

Posted by – 12/03/2012

Just as I promised yesterday, I pushed a new git repo with my fork of the tool I used to migrate my old Mephisto blog to this new WordPress one.

I forked because the tool have not worked the first time. First of all, I was missing uuidtools gem, and to install it would be a pain inside the jail system I used to run my blog. Too much trouble just to get a UUID we can get by other means… so I just added an environment variable UUIDGEN anyone can use to point to a tool to do the job. I know this have performance implications, but I am not talking about 10-thousand entries…

Then, I found out that, for some odd reason I still have to understand, WordPress was cutting my articles everytime it read a “à” character. I could study the subject, but I just added a #gsub in mephisto-to-wxr code and moved on. I was about to remove it from the repo, but I left it there since it could help other people. Also, since there might be other similar occurrences, leaving it there serves as a heads up.

Also, I added support for Categories and Tags to mephisto-to-wxr, that seemed to be limitedly accepted (I translated Mephisto Sections into WordPress Categories).

All other activities were just clean-up. That tool generated a .WXR with all the articles and comments from my Mephisto blog. Everything I had to do was import it using WordPress import tool.

Mandando pro Subversion algo que só existe no git

Posted by – 17/07/2009

Eu não sei bem por que tem pessoas que acham que eu sou um expert em git… Caras: só porque eu mantenho alguns projetos no GitHub não quer dizer que virei expert. Toda semana tem algum email para mim perguntanto alguma coisa sobre git… A maioria eu consigo responder já que é coisa básica (ou aponto para alguma documentação e pronto), mas ontem veio uma pergunta meio estranha: Como mandar para o subversion algo que, até o momento, só existe em git?

Essa é interessante… Até agora eu não tinha precisado disso: só estava usando o git para manter projetos que já tinham começado no subversion da empresa… Pesquisando um pouco e adaptando para o estilo de trabalhar da Propus, eis minha proposta:

bash$ cd /caminho/para/o/projetoX
bash$ svn mkdir https://servidor.svn/projetoX -m "Importando do Git"
bash$ svn mkdir https://servidor.svn/projetoX/trunk -m "Importando do Git"
bash$ git checkout -b svn
bash$ git svn init https://servidor.svn/projetoX -s
bash$ git svn fetch
bash$ git rebase trunk
(aqui eventualmente o git se "perde", e algum conflito é gerado. Nos
projetos em que isso aconteceu para mim, um "git add arquivo-com-conflito"
seguido de um "git rebase --continue" foi o suficiente).
bash$ git svn dcommit

Com isso você tem um branch chamado svn que vai espelhar o que está no subversion. A partir de então e só seguir mantendo o código no master (ou em algum branch que quiser), fazer o merge com o branch svn e mandar para cima com um git svn dcommit

Git basics: reversing the ‘git sucks’ effect

Posted by – 19/02/2009

I’ve been using git this last few days and I am still working on a workflow for my projects. Unfortunately, as others have noticed, git violates POLS is so many ways, it ends up being hard to get.

Creating a remote repository seems to be the first thing to bite a developer switching to git (mainly if coming from a centralized SCM). I have not decided which is the best way of doing it, but I’ve been using git-daemon via inetd and a path in my remote hosting holding all my repositories for public pulling, and ssh for pushing. Here is how to create it:

local$ ssh spectra@remotehost
remotehost$ mkdir /var/git/myproject.git
remotehost$ cd /var/git/myproject.git
remotehost$ git --bare init
remotehost$ logout
local$ cd myproject
local$ git remote add remotehost spectra@remotehost:/var/git/myproject.git
local$ git push remotehost master
...
otherlocal$ git clone git://remotelocal/myproject.git
otherlocal$ cd myproject
otherlocal$ git remote add remotehost spectra@remotehost:/var/git/myproject.git
(hack hack hack)
otherlocal$ git push remotehost master

Now everybody can pull your repository at git://remotehost/myproject.git and you can push and pull to it via ssh. Note that you have to setup git-daemon, which is pretty straight forward. I am using it as an inetd daemon, but you can use it as a standalone one. Debian has a package which does just that.

Now, some people think logging in a remote server just to create an empty repository is too much. Well… repositories are just .git directories. It happens that you can “push” for the first time by rsyncing your .git with a remote host:

local$ cd myproject
local$ rsync -a .git/ spectra@remotehost:/var/git/myproject.git
local$ git remote add remotehost spectra@remotehost:/var/git/myproject.git
(hack hack hack)
local$ git push remotehost master

(Apparently you can “push” using rsync every time, but it’s regarded as wiser to keep your – probably – crappy local repository commits separated from the public repository… otherwise commit messages like “Please, don’t use this code” are likely to pop up everywhere 🙂 ). Now, I don’t know if this have side effects, but it works 🙂

Another thing to notice is that git is more directed at pulling than pushing. This may be because of its designer: the way Linus works is by pulling changes from others’ repositories and not by letting others push’em into his one. And this is another violation of POLS for most of the people, who is used to “commit” their changes into some remote repository. Rather than that, people using git would expose their own repositories in order to have it pulled by others.

I also agree with most of the git critics wrt git commands… There’s a lot of examples – and I am not going deeper in this – but I think it was a bad choice calling “checkout” what git does when told to “checkout”, for instance. Yes, I know… different tools, different ways of seeing it… but everyone was already used to what centralized SCMs call their operations, and I think it would only help git adopting same names for the same operations, and inventing new ones for those proper of decentralized operations. Anyway, once you get it (and I have not completely got it yet), it seems all flow as expected. If this adaptation fails, there’s still Easy Git to the rescue!

One last thing that I think contribute to the “git sucks” effect: git-svn. This is a great tool, but it was built from git’s point of view… Given it’s intended as a glue for Subversion newcomers, it would benefit more from being built from svn’s point of view. This was mentioned by a colleague developer in my company, when he just couldn’t understand why one have to git svn rebase instead of a simple update. So git-svn also suffers of the “bad command naming habit” git do. Of course, that given that you came from this environment (I am sure git and git-svn makes perfect sense for Linus & cia 🙂 ). I have not tried yet, but yap seems to be targeted on providing an alternative to git-svn.

GitHub saving space?

Posted by – 07/02/2009

I was browsing GitHub, getting to know the system and feeling pretty amazed by it (seriously… I felt I discovered Orkut for developers)… when some thought just stroke me: how do they save space?

Yes, I know git is pretty efficient when it comes to saving space. Yes, I also know that space are becoming cheaper with time, but still, they claim to have +50k developers hooked up their servers… if they’re not doing something about space, things will go inefficient quite quickly. Rails alone seems to have 464 forks! If all of them represent one bare clone of the ‘canonical’ repository on GitHub’s side, that is a lot of space wasted in duplicated things…

Git has one amazing feature: hashing the objects it keeps track of. It surely doesn’t seem too complicated to design a schema that avoids having two copies of objects with the same hash. So all those forks of Rails, on GitHub’s side, would be just hardlinks to the ‘canonical’ repository…

Surely people working in GitHub are smart enough to have though about it on their own… Who knows? Maybe that’s exactly what they’re doing already! If so, can I ask them to share their schema, since it can become very useful to the rest of us? If not, can we beat them ;-D?

Alright! I surrender: Git rules!

Posted by – 05/02/2009

Everybody seems to be using git these days… I am not very found of “hypes”, as I told you before, but there’s been some time I’ve been evaluating git. I was happy with svk for quite a long time… Lately, though, I’ve been developing and extending a lot of ruby libraries, and all of them seem to be hosted at GitHub and using git… So, why not give it a serious try?

I chose a simple task on my TODO-list: to extend xmpp4r-simple to support XMPP PubSub, so I could use it in an internal project at my company. So I “cloned” its git repo and started developing. Not a really hard task, since all I had to do was use the underlying library (xmpp4r – not surprisingly also in GitHub) and mimic what Blaine’s done for the callbacks and it was ready (and working… although I still need to put more time on the test suite).

I am still exploring… It will take some time to migrate my stuff (and maybe a lot will remain in my company’s Subversion), but that’s what git-svn is for, isn’t it? Right now I am looking for ways to work with git-buildpackage and Debian git tools… Do you have some advice on that?

Considering git…

Posted by – 23/04/2008

It has been some time since I’ve blogged about Subversion and how I was finding it useful. I’ve been using subversion and svk since about that time and I love it. Svk is really great and although it is more an off-line version control than a distributed one, it goes a long way for a former cvs user like myself. Lately, I’ve been considering git (isn’t everyone?).

It was not until I moved to my own hosting (thus having to maintain two subversion trees: the new one and my company’s old one) that the whole “having a central repository” started bothering me. Merging became complex, since now I have two “central” repositories, and while svk makes it a lot simpler (I just keep a mirror of the two repositories and use svk to merge between them), I began to realize that there should be a better way… I’ve watched (again) Linus’ git lecture at Google Tech Talks and decided I was going to try it.

First thing that called my attention was how easy it is to share a repository: just copy the .git directory somewhere public (an http server, for instance), and there you have it. This is much easier than configuring modules for apache, or configuring svnserve (and I’ve done that a lot in the past 3 years!).

For the subversion-only user (one that has never used svk), the carry-all-the-repository-with-you thing may sound strange, but with svk, I was used to “mirror” the repository, so that’s not an important change to me. I could not compare space utilization (and git is advertised for being more space-efficient) yet, but so far the git repositories seems to be a little smaller.

I already found it easy to branch using svk (in fact, I used to do that a lot), but git branching is really a plus! You can switch back and forth inside the same ‘working copy’ (actually I don’t think it’s correct to call that a working copy) and merging is rocket-fast! Maybe if svk could easily merge between two distinct users without requiring a subversion repository (think about the defunct svl), I would not have been trying git, but…

One thing that is really missing is the partial checkout. Actually I liked very much that svn/svk “feature”, and the clean and natural way which they treat directories and files. I understand git is designed with other priorities in mind, but, right now, that feels like missing to me. Maybe it’s just a svn/svk habit.

All in all, I found git very interesting… I am not ready to switch from svn/svk yet, but I’ll try git in small new projects and see if I can get used to it.