Exiv2

As KDE developer who has follow svn to git transition, i can said, that git, is powerful, but too powerful. It's a bulldozer to make a small hole (if i talk about Exiv2 project). This tool is perfect to manage huge projects, with a large amount of developers / contributors (as Linux), but for medium and small projects, git is not very well adapted.

Too much commands are obscurs and complicated compared to svn. Personalty, i take one year of active development with digiKam & co to drive git in medium level. I discovers new options everyday.

So, a svn to git transition is not a small task. Take a care. I recommend to do it when time permit after a major release.

Gilles Caulier

I've been using git for my Exiv2 development (however little that has been lately) for quite some time, using the git-svn extension (see below). Nothing should stop you from doing the same, although I'm not sure how that feature about contributor-ship works in this setup. But I agree with Gilles: Git is not a simple tool, and I have no problem getting myself into a situation where I don't know what to do anymore after issuing just a few git commands. But thanks to the git-svn extension, we can have an svn repository, which is all we really need, and anybody who likes can still use git for their local development (we even have a .gitignore file in the repository).

These are the few commands I use (copied verbatim from an old email from Volker Grabsch from 2011):

[1] If you want to get started, I recommend to run the following command:

        git svn clone -s svn://dev.exiv2.org/svn exiv2

    This will take a while. It will download the whole history of trunk
    and all branches. Afterwards, the working directory will point to
    the latest trunk revision. Afterwards, you should optimize the repo:

        cd exiv2
        git repack -ad

    Note that for Exiv2, the overhead of Git is just 12 MB, containing
    the whole history. Compare this to Subversion's overhead of 27 MB
    containing just the latest revision.

    Instead of "svn update", you'll do:

        git svn rebase

    Instead of "svn commit", you'll do:

        git commit -a
        git svn dcommit

    For more information, there are nice tutorials and manuals. [2]

    There's only one drawback: It is tricky to add commit messages
    that start with a hash (#), because such lines are usually ignored
    by git. There are some ways to circumvent this [3], the easiest is
    not to use a text editor but to provide the commit message at the
    command line:

        git commit -a -m '#772: Applied patch to recognize ...'
        git svn dcommit

[2] http://www.viget.com/extend/effectively-using-git-with-subversion/
    http://www.kernel.org/pub/software/scm/git/docs/git-svn.html
    http://git.or.cz/course/svn.html

[3] http://stackoverflow.com/questions/2788092/start-a-git-commit-message-with-a-hashmark

Andreas

Seriously I read your comments about git being more difficult than svn, but I really don't get it. That's just another program, and as such obviously you learn new paradigms. It's all just a question of getting used to it, basically. Isn't it what we constantly do as software developers (new languages, new programs, sometimes that we build, sometimes that other did)?

As for my own, I used to use svn regularly, years ago. And I was therefore more proficient than I am with git. Nowadays that's the opposite. There are so many things I don't know how to do anymore with svn, but they just come naturally with git. Why? Not because svn is about "homeomorphic endofunctors" or some other funny (or not) joke. Just it's about getting used to new tools. To get back at your example of getting into a blocking situation, I actually had it the other day with a svn project, which forced me to check it out from scratch because I could not find how to reset cleanly my repo (note: I don't say it is not possible, just that I could not find how!); whereas with a git project, I can always come back to a bare repo in a few commands, and this even without a working connection. The point is that this was not a good example because it can be reversed too, since it just all depends on how proficient one is with a particular tool. :-)

Anyway I was just saying, I should maybe not have brought this topic up. Also about saying Exiv2 has few contributors: maybe it could have more with a versionning system which encourages people to contribute (i.e. not svn). Exiv2 is getting used in quite a bit of big projects now, and metadata is a big topic nowaydays (in Libre Graphics Meeting, there are always a few conferences/workshops related to metadata). No reason Exiv2 could not get much more contributors.

I don't have any issue with the idea of adopting git. I've only heard good things about it. My reluctance is the period of confusion as the team comes up to speed. I'll put this on the agenda for the next team meeting. Provided a team member agrees to be "Mr Git" and hand-hold us through the inevitable pain of adoption, I'm OK about this. No "Mr Git". No Way!

I think this is a Python vs Perl, C++ vs C kind of thing. The superiority of the new guy on the block is not in doubt. However the frustration during the adoption period is real. Something to deal after we've shipped 0.25.