[OSM-dev] OSM binary format (pbf) 1.0 is in osmosis trunk.

[Greg Troxel]

Frederik Ramm <frederik at remote.org> writes:

I've been the chief SCM crank at work for close to 15 years.  We used
CVS exclusively for a long time, and I didn't allow people who said "foo
is shiny this week; we should switch" to change our world because none
of them could answer the challenge of "prove foo is stable and we'll be
comfortable getting bits back out of it for 10-20 years" until fairly
recently.  We started using svn in 2007 and in 2010 started a very large
project in git.

This is a bit lengthy, but I was a git skeptic for a long time mostly
because a lot of people seem to say/mean "I haven't listened enough to
understand your problem but the answer is that you should use git."
I've recently gone through a trade study to choose a VCS for a hairy
project, and ended up with git.  So I can understand a bit of where
those people are coming from.

> I don't like git, and I especially dislike github (not using
> sourceforge either); but that's a personal thing, so don't let that
> discourage you from continuing to use it for development. I'll just
> make sure every now and then that there is a working version in SVN.

I can certainly see the point of avoiding free-as-in-beer services with
non-free-as-in-speech toolsets and changeable procedures.  But I think
that's orthogonal to tool choice, and OSM seems to have resources to
host a VC server.

> (My dislike of git stems largely from ignorance and is likely to
> vanish over time. At the moment I have grown used to the one-stop-shop
> that is our SVN; with git I miss the option to say "check out all OSM
> projects", as well as the option to commit to trunk for all OSM
> projects without first signing up to external services and/or find out
> who the maintainer is and ask them for permission.)

You are conflating two separate things, which is the nature/capabilities
of the tool itself and the cultural norms that typically are associated
with the tools.  I've recently been through this and found that the
git-using community does have notions that are separable from tool
issues, and I think your objections boil down to "I don't like the way
people who like git tend to do things" much more than "git isn't a good
tool" (and I basically agree with you).

Git culture has a notion of every person having a public repository,
with very limited commit privileges on the official repository.  This is
just culture, and not forced by git.  On my project, we have a machine
with the official repository, and everyone on the project can both check
out that repository and push to it (over ssh).  So from an access
control point of view, it is exactly like SVN.  The norms of who can
change what bit of code with or without are handled just as in SVN, by
social pressure outside the tool.

I find the current osm SVN to be problematic, because there are a
collection of various things in it (which is fine) but there is not a
uniform structure for the trunk/tags/branches (TTB) levels.  In my svn
repos at work, we basically require that each module foo have TTB below
it, and thus all URLs look like /foo/trunk/README.foo.  We have a
CHECKOUT-ALL script which grabs foo/trunk/ to foo, so one sees the
logical structure in a checkout, and can svn switch to branches per
module.  svn lets you do this, but it doesn't make you, and it's easy to
make a mess if you don't follow a rule like mine.

So I don't understand how you can say "one stop checkout", because I
find that if I checkout the whole tree I get vast amounts of old
branches and tags that take up rather a lot of space and make a huge and
messy working copy.

In git, branching and access control can only be done on the whole repo,
so people (reasonably) put separate chunks of code in separate
repositories, rahter than using separate namespaces and perhaps authz in
svn.  git's weakness is that the ways to gie those separate repos
together are all not entirely satisfying (submodules, android's repo
script).

Consider if OSM used git, and for each logical thing in SVN there was a
git repo on git.openstreetmap.org, but that all users with a commit bit
could push to all repositories.  Then with osm-cm repository that has a
script CHECKOUT-ALL that clones/updates every single repository on the
list (sort of recreating android's repo script) you have basically
recreated the svn cultural norms with another tool.

git has two basic advantages over svn: offline use and dealing with
unprivileged users.  I have found the offline part useful, where I have
full history and can make commits that I later push.

Git also supports people who can't write to the official repository
cloning and making local commits anyway.  This is better than svn for
two reasons:

  people can keep their local changes in the tool, and keep merging
  upstream.

  people can publish their changes via format-patch or making a repo
  available, and then those than can write to official can grab their
  changes staying entirely within the tool - it's much easier than
  patches in email, and preserves all the commit metadata.

The problem is that parts of git culture basically say that because one
can use the no-commit-privs-many-repos scheme that such a scheme should
be the primary way to work.  The key question, as with svn or anything
else, is who is allowed to make changes to the official repo.  With git,
integrating work done by those not on the list is easier, which may tend
to have people chooes to make the authorized committer set smaller.

One of the things that I found on my project was that some people who
were used to git said "every person should have a public repo on the
server".  I said that I didn't want that, and no one was able to come up
with a good reason for per-person repos, because the real motivation to
have a personal one is that you aren't allowed to write the official
repo.  Plus, I asked that branches be about features/etc., not about
people.  I have commit rights at gpsd and quagga, which both use git,
and I have no published personal repositories.  When I want to make a
test branch available to others, I just push it to the official
repository.  So my usage is closer to svn in terms of public repo
structure - but I still get offline support and the ability to more
easily integrate the work of non-committers.

My trade study looked at hg and bzr.  Basically all the modern DVCS
systems are similar and it comes down to minor issues and mindshare - we
decided git won on mindshare.

I think what's going on now is that we have a svn repo that git weenies
don't particularly care for, and no git repo support on osm servers, and
that people are therefore basically setting up git repos elsewhere for
various pieces and perhaps not all that concerned about making the svn
repo be the authoritative source.  I believe that the git-svn tools ease
putting git commits back into svn, so it's probably just as well that
a git user with svn access use them.

    Greg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20101017/70c0cecb/attachment-0001.pgp>