[OSM-dev] OSM binary format (pbf) 1.0 is in osmosis trunk.
scrosby at cs.rice.edu
Sun Oct 17 20:35:14 BST 2010
> Not what I want, because
> (1) every project will have to have a maintainer who decideds what gets
> pulled into trunk - this introduces more formality than we have now;
> (2) as a committer, I want it to be *my* decision whether I commit
> something right away - in cases where I'm sure it is good - or whether I
> want to discuss with others first. That's in keeping with the spirit of OSM
> where you don't have to ask for permission to edit the map.
These two points are a function of ACL policy and development customs. Not
of the choice of revision control system.
> (3) as a user, I will have to hunt through mailing lists and whatnot and
> compile the cryptic URLs of private repositories to pull from, rather than
> having a one-stop shop.
I'd like to note that the only reason I used a cryptic github URL was
because I didn't have an SVN account in which to do my development. True, I
did not ask for one. Would one have been given had I requested? Now that the
pbf project is finishing up, it *needs* to be in OSM's repositories, with an
openstreetmap URL. The only reason it is not done yet is because I've not
had time to try to understand the layout to figure out where I should put my
> I can see git being useful for something like the Linux kernel, but I can't
> see advantages for OSM at the moment. The "different mentality" you speak of
> is probably what I object to; compared with a classic SVN project where you
> have only a handful of committers, git may offer more flexibility but
> compared with OSM where everyone gets SVN access...?
The advantage of GIT and having local repositories is that commiters have a
place to clean up their patches before submitting. With SVN, there's no
distinction between 'commit' and 'publish'. With GIT, there is. I can commit
one or many times into my local repo during development. I can split up
bugfixes or refactoring from new development. I can even go back and revise,
reorder, and merge those patches. When I chose to, I can publish one or many
of those changes. That is why I use GIT locally for everything.
> But as I said - it doesn't have to be either-or, you can go ahead with the
> cutting edge development on git and we can every now and then pull something
> workable into SVN, with a big README that says please apply changes to git
A central GIT wouldn't be different than SVN for what I have been doing. I
do my development locally in GIT, then push to central SVN when it is ready.
I also push my working state to github more frequently as a backup or if
anyone wants to see what I've been up to.
There's probably not a big advantage for OSM to use GIT instead of SVN
centrally. The advantages of GIT over SVN in that case comes in when
development is so rapid that collaborators need to do merge and integration
work *outside* of the central repository. OSM development patterns don't
seem to need this usecase.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dev