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

[Greg Troxel]

Frederik Ramm <frederik at remote.org> writes:

> OSM already has a git repository but this is currently only used for
> the rails port - where I have to admit it makes some sense, as the
> rails port software happens to be more controlled than other stuff in
> that the admins must closely watch what gets deployed on our main
> servers.

But having a separate SVN repo, or a separate acl on part of the svn
namespace would do this too.  Once you're setting up new, though, I too
would choose git over svn because a DVCS has a lot of advantages.

>> 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.
>
> ... as I explained in another mail to Stefan, it always seemed to me
> that the git world is more control-freakish which probably stems from
> what you say above; if you can tell every would-be commiter to use his
> private repo then you can afford to be.

True.  Ask "in a project, when do you decide to hand out commit bits?"
There's always a risk of people doing things you wish they wouldn't,
plus a cost of time to review/integrate and the cost of work that isn't
integrated or just doesn't happen.  So there's a tough judgement call.
Most projects with centralized repos tend to apply a "when it's more
work to review/apply their work than it would be to clean up from their
mistakes, and when we feel comfortable about their judgement" kind of
test.

git changes this calculus, because review/apply comes down to 

  # normal update procedure
  git branch master
  git pull

  # set up to take changes from johndoe
  git add remote johndoe http://blahblah
  # grab all feature branches from johndoe and everyone else
  git remote update -p

  # study change
  git log -p origin/master..johndoe/feature-foo
  # merge it
  git merge johndoe/feature-foo
  # test
  [do testing]

  # send the changes to the world
  git push

which after you've done it twice is almost entirely the real work of
reading the diffs and testing (and just believing people is less of a
leap than giving them commit access), with almost no effort in patching
-- plus the attribution/date of the original feature branch is preserved
without any real work.

Given this, the rational choice for when to give out commit bits shifts
slightly in the direction of waiting a little longer.

>> 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.
>
> So maybe there *is* a way to have the best of both worlds yet.

I think there is.  Basically (very broad brush here, without
justification), switch to git, but be thoughtful about the cultural
norms and access control model.  I'm surprised to find myself being such
a git advocate - I really didn't start out that way before my trade
study and use of it.

One thing that isn't obvious is that SVN is better about acls (because
you can use authz to give different people access to different parts of
an svn repo) but git is better at offline use and work by
non-committers.  The nature of DVCS where you get the entire repo state
is inconsistent with less-than-single-repo *read* access control, and
fine-grained write control appears to be messy and not done in practice.
So I think to get svn-style acls and a distributed system, you need 1
git repo per acl domain, and then a multi-repo setup to manage it.

-------------- 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/b8c514e4/attachment-0001.pgp>