Re: [reSIProcate] the git question
> The general argument against such a move is that it requires people to learn
> a new technology just to continue doing what they (otherwise) already know
> how to do. I sympathize with this to some degree, but I'm not necessarily
> against progress if the benefits can be described and clearly outweigh the
> effort to migrate.
>
I agree - but git has become very widespread now, so
a) people might have to learn it anyway (for working with some other
projects that they want to participate in)
b) although it is not the case today, there will come a time when new
people coming to the project might have git skills but not SVN skills
Also, from my own experience, I believe it is easier to approach this
learning curve on familiar territory - in other words, on projects I
already know
> Personally, I'm an extreme beginner when it comes to git, and I find its
> basic operations to be both arcane and obtuse. I've used SCCS, RCS, CVS, SVN,
> and ClearCase; and, while they all do things somewhat differently, the
> general conceptual model among them is the same. Git seems to turn model this
> on its head, making the learning curve fairly steep.
I agree, it definitely has the appearance of a steep learning curve. I
don't think I'm yet to learn enough to consider myself an expert.
However, once you start hacking about with it and figure out how to do
the things you do every day, you will find you are not so put off by the
fact you (like many git users, myself included) don't understand
everything it can do.
I worked on Ganglia for a while (as release manager and as a
contributor), I've recently started ganglia-modules-linux using git
exclusively, and I've found it to be significantly less painful than SVN
releases.
> As someone who uses both git-svn and native git, can you outline the benefits
> of using git natively over using the git-svn approach?
Using git-svn is a bit like an svn checkout on steroids:
- you mirror the whole SVN repo into your local disk (even on a laptop)
- browse any changes or log messages in the SVN history
- make your own local commits (you can even commit without network
access) or even make whole new branches in your local workspace
- and then at some later point you can cherry pick some or all of your
local branches or commits and push them back to the SVN project
You can actually see the way it pipelined all my commits back in to SVN
together (notice the very short gaps, just seconds, between every commit
on my branch?)
https://svn.resiprocate.org/viewsvn/resiprocate/branches/b-dpocock-autotools/?view=log
Anyone can start doing that now
The drawback: git-svn adds slightly more complexity: not only do you
have to learn git, but you have to learn about how git-svn maps the git
branches to svn branches. It's not rocket science, but it is just more
detail to keep track of, and it can muddy the waters at the very time
when you are trying to break loose from SVN thinking and adopt the
mindset of a git user.
One other drawback of git-svn: because you are accumulating commits (and
even branches) on your local disk, you really need to think about
backup. You could have gone for 2-3 weeks making commits locally, but
it is not in the server-side repository, it is only on your local disk,
so if you are not used to doing some daily backup of your home directory
or laptop, you need to take responsibility for adding that in to your
workflow. The same issue arises even without git-svn, but with straight
git, it is slightly easier to backup to multiple repositories (e.g.
completed changes to the main resiprocate repo, while work in progress
or changes on your in-house proprietary branch might go back to a local
server only - git can handle all of those workflows)
The bottom line: it would actually be easier for people to learn git if
the whole repo was just changed over to git - then people don't need to
worry about learning the git-svn tool as well
As a first step, I'd suggest
- build a git repo that people can checkout from (there is a simple tool
for this, it is a one line command) and people can play with it,
- try some routine tasks (e.g. checkout, change, commit, branch, merge, tag)
- play with it for 4-6 weeks, almost like a parallel running,
- then throw it away and do the real conversion (if everyone accepts the
idea)