Part of Slepp's ProjectsPastebinTURLImagebinFilebin
Feedback -- English French German Japanese
Create Upload Newest Tools Donate
Sign In | Create Account

Miscellany
Monday, June 4th, 2007 at 3:25:51pm UTC 

  1. From: Linus Torvalds <torvalds <at> linux-foundation.org>
  2. Subject: Re: Git Vs. Svn for a project which *must* distribute binaries too.
  3. Newsgroups: gmane.comp.version-control.git
  4. Date: 2007-06-04 15:20:16 GMT (3 minutes ago)
  5.  
  6. On Mon, 4 Jun 2007, Bryan Childs wrote:
  7. >
  8. > 1) Due to the nature of our project, with multiple architectures
  9. > supported, we strive to provide a binary build of our software with
  10. > every commit to the subversion repository. This is so that we can
  11. > provide a working firmware for the majority of our users that don't
  12. > have the necessary know-how for cross-compiling and so forth.
  13.  
  14. Git has no problems with binaries, but I _really_ I hope that you don't
  15. actually want to check these binaries into the repository? You could do
  16. that, and the git delta algorithm might even be able to compress the
  17. binaries against each other, but it could still be pretty nasty.
  18.  
  19. And by "pretty nasty" I don't mean that git won't be able to handle it: I
  20. suspect it's no worse from a disk size perspective than SVN.  But since
  21. git is distributed, it means that everybody who fetches it will get the
  22. whole archive with whole history - it means that cloning the result is
  23. going to be really painful with tons of old binaries that nobody really
  24. cares about beign pushed around.
  25.  
  26. So I *hope* that you want to just have automated build machinery that
  27. builds the binaries to a *separate* location? You could use git to archive
  28. them, and you can obviously (and easily) name the resulting binary blobs
  29. by the versions in the source tree, but I'm just saying that trying to
  30. track the binaries from within the same git repository as the source code
  31. is less than optimal.
  32.  
  33. > 2) Unlike the Linux Kernel, which Linus uses as a prime example of
  34. > something git is very useful for, the Rockbox project has no central
  35. > figurehead for anyone to consider as owning the "master" repository
  36. > from which to build the "current" version of the Rockbox firmware for
  37. > any given target.
  38.  
  39. The kernel is really kind of odd in that it has just a single maintainer.
  40. That's usually the case only for much smaller projects.
  41.  
  42. And no, git is not at all exclusively *designed* for that situation,
  43. although it is arguably one situation that git works really well for.
  44.  
  45. There is nothing to say that you cannot have shared repositories that are
  46. writably by multiple users. Anything that works for a single person works
  47. equally well for a "group of people" that all write to the same central
  48. git repo. It ends up not being how the kernel does things (not because of
  49. git, but because it's not how I've ever worked), but the kernel situation
  50. really _is_ pretty unusual.
  51.  
  52. So git makes everybody have their own repository in order to commit, but
  53. you can (and some people do) just view that as your "CVS working tree",
  54. and every time you commit, you end up pushing to some central repository
  55. that is writable by the "core group" that has commit access.
  56.  
  57. In *practice*, I suspect that once you get used to the git model, you'd
  58. actually end up with a hybrid scheme, where you might have a *smaller*
  59. core group with commit access to the central repository (in git, it
  60. wouldn't be "commit access", it would really be "ability to push", but
  61. that's a technical difference ratehr than anything conceptually huge), and
  62. members in that core group end up pulling from others.
  63.  
  64. But that would literally be once you have gotten used to the git model,
  65. and you can start out just totally emulating the old CVS/SVN model with a
  66. single central repository.
  67.  
  68. > 3) With a central repository, for which we have a limited number of
  69. > individuals having commit access, it's easy for us to automate a build
  70. > based on each commit the repository receives.
  71.  
  72. .. and that's exactly how you'd do it with git too. You wouldn't have a
  73. "commit trigger", but you'd have a "receive trigger", which triggers
  74. whenever somebody pushes to the central repository.
  75.  
  76. And that does mean that a developer might do a series of _five_ commits
  77. locally on his own machine, and they are totally invisible to everybody
  78. until he pushes to the central repository: and then the build will build
  79. just the top-most end result commit. So you'd not necessarily have a
  80. binary for _each_ commit, but:
  81.  
  82.  - you could (if you really wanted to) actually force people to always
  83.    send just one commit at a time. You could even enforce that in the
  84.    pre-receive triggers, so that people *cannot* push multiple commits at
  85.    a time.
  86.  
  87.    Quite frankly, I really don't think you want to go this way. I think
  88.    you want to perhaps _encourage_ people to send just one commit at a
  89.    time, but the much better model is the other choice:
  90.  
  91.  - realize that the git model tends to encourage many small commits
  92.    (because you *can* make commits without impacting others), so when you
  93.    fix something, or add a new feature, with git, you can do it as many
  94.    small steps, and then only "push" when it's ready.
  95.  
  96.    IOW, if you encourage people to do small step-wise changes, you
  97.    probably don't even *want* a build for each commit, you really want a
  98.    build for the case where "my feature is now ready, I'll push". So you'd
  99.    effectively get one build not per commit, but per "publication point".
  100.  
  101. But anyway, it really boils down to: you *can* use a distributed
  102. development model to emulate a totally centralized situation (put another
  103. way: "centralized" is just one very trivial special case of
  104. "distributed"), but I suspect that while you might want to start out
  105. trying to change as little as possible in your development model, I
  106. equally strongly suspect that you'll find out that the distributed nature
  107. makes _some_ changes to the model very natural, and you'll end up with
  108. more of a hybrid setup: aspects of a centralized model, but with
  109. distributed elements.
  110.  
  111.                 Linus

Update the Post

Either update this post and resubmit it with changes, or make a new post.

You may also comment on this post.

update paste below
details of the post (optional)

Note: Only the paste content is required, though the following information can be useful to others.

Save name / title?

(space separated, optional)



Please note that information posted here will expire by default in one month. If you do not want it to expire, please set the expiry time above. If it is set to expire, web search engines will not be allowed to index it prior to it expiring. Items that are not marked to expire will be indexable by search engines. Be careful with your passwords. All illegal activities will be reported and any information will be handed over to the authorities, so be good.

comments powered by Disqus
worth-right
worth-right