{"thread":{"id":"8478","subject":"Re: Git Vs. Svn for a project which *must* distribute binaries too.","startedAt":"2007-06-07T04:36:32Z","lastAt":"2007-06-08T20:41:01Z","messageCount":4,"participants":["linux@horizon.com","Bryan Childs","Jan Hudec"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"44224","messageId":"20070607043632.31891.qmail@science.horizon.com","threadId":"8478","inReplyTo":null,"subject":"Re: Git Vs. Svn for a project which *must* distribute binaries too.","fromName":"","fromEmail":"linux@horizon.com","sentAt":"2007-06-07T04:36:32Z","receivedAt":"2007-06-07T04:36:32Z","isPatch":false,"sender":{"key":"linux@horizon.com","avatar":null},"body":"There's no reason that git can't do everything you have svn doing.\nWhat SVN calls \"commit access\" is what git refers to as \"push access\",\nbut it's exactly the same thing. I don't see how it's the tiniest bit\nmore difficult.\n\nThe only difference is that in git, it's a two-stage process: you commit\nlocally, and then push that commit (or, more commonly, a whole chain of\ncommits) when it's ready. But to the receiving repository, it's just\nanother commit.\n\nYou can have a central server, just like you have with SVN, and when it\ngets new versions, it can auto-build them and do whatever it likes with\nthe binaries. (Including stick them in the same git repository, or\na different one.)\n\nThere's no need for such a central repository to be \"owned\" by one particular\nperson. You can have a shared repository with multiple people having commit\naccess. Linus likes to keep very tight security over his master repoisitory\nand only pull, but git supports a shared-access repository just fine.\n\nThe only thing, and it's not a very big thing, is that if you want\nfine-grained access control, you have to implement it yourself via the\npre-receive hook rather than having a canned implementation ready.\n\n\nAs for making a binary of every commit, git encourages a slightly\ndifferent workflow:\n- Because commits are very easy, and private (until pushed), you're\n encouraged to make lots of small commits. I used to hold of committing to\n CVS if working on a big patch. Now, I use git freely on a private branch\n to keep track of my own hacking.\n (git-gui is nice for encouraging me to commit frequently. As I make\n edits, I write the commit message and watch the patch grow. When it\n gets big enough, click \"commit\" and keep going. I have a perfectly good\n memory, but after three phone calls, two \"just a quick question\"s and\n an impromptu meeting, the notes make it quicker to get back into it.)\n- If you later decide the commits aren't something you want to show the world,\n then don't. You can cherry-pick the good ideas and kill the lousy ones.\n- The simplest example of this is \"git commit --amend\". Git lets you\n commit before testing, and if you find some stupid typo that prevents\n the code from even compiling, you can just fix it and re-do the commit.\n *Poof*, your embarassing mistake just disappeared.\n (When learning git merges, it took me a log time to get over my fear of\n committing a mis-merge. With git, it doesn't matter; it's just as\n easy to undo a commit as to do one, as long as you haven't published\n the results.)\n\n- On the other hand, if you want to enjoy the full benefits of git-bisect,\n which can let J. Random Bug-submitter find the commit that caused a\n regression while you eat chilled grapes on the beach, you want both\n small commits and commits that don't break the build. So cleaning up\n your history before publishing can be a very worthwhile effort.\n This is a step that many people aren't used to doing, and you don't\n need to force it on your developers. Linus has long required such\n efforts, to make code review easier, but there are different traditions.\n But it really does make tracking down bugs a lot easier.\n\n\nAnyway, because of the small-commit tendency, you might want to only\nbuild one binary per push, not one binary per version. (Oh, I should\nnote that it is perfectly legal to push an old version that the receiving\nrepository already has. It has no effect on the repository, but you\ncould have it tickle your autobuilder. Check with someone who knows\nwhether git even runs the commit hooks in that case, though.)\n\nBut you can do whatever. git-archive is a useful little tool for getting\nsource snapshots to compile.\n\nOnce you've built the binary, you can, if you like, put it into a git\nbranch by itself. You could even put it in the same repository as the\nsources, but with a totally disjoint history, but if you never intend\nto merge the branches, that just complicates your life and increases\nthe chance that somebody will clone that branch. It makes more sense\nto use a separate repository.\n"},{"id":"44237","messageId":"5971b1ba0706070057l2d4b170emd8af733d888d6a56@mail.gmail.com","threadId":"8478","inReplyTo":"20070607043632.31891.qmail@science.horizon.com","subject":"Re: Git Vs. Svn for a project which *must* distribute binaries too.","fromName":"Bryan Childs","fromEmail":"godeater@gmail.com","sentAt":"2007-06-07T07:57:31Z","receivedAt":"2007-06-07T07:57:31Z","isPatch":false,"sender":{"key":"godeater@gmail.com","avatar":"https://gravatar.com/avatar/9a89d9013a02939600457d86d6f5bc9f8718fa23fba71bb4c720f4ae087afc62?d=mp&s=160"},"body":"On 7 Jun 2007 00:36:32 -0400, linux@horizon.com wrote:\n> There's no reason that git can't do everything you have svn doing.\n> What SVN calls \"commit access\" is what git refers to as \"push access\",\n> but it's exactly the same thing. I don't see how it's the tiniest bit\n> more difficult.\n\n\n\nThanks for this extremely length and informative reply - it's answered\nall our concerns, and we may well move to git sooner rather than later\nnow!\n\nBryan\n"},{"id":"44250","messageId":"20070607165150.27434.qmail@science.horizon.com","threadId":"8478","inReplyTo":"5971b1ba0706070057l2d4b170emd8af733d888d6a56@mail.gmail.com","subject":"Re: Git Vs. Svn for a project which *must* distribute binaries too.","fromName":"","fromEmail":"linux@horizon.com","sentAt":"2007-06-07T16:51:50Z","receivedAt":"2007-06-07T16:51:50Z","isPatch":false,"sender":{"key":"linux@horizon.com","avatar":null},"body":"> Thanks for this extremely length and informative reply - it's answered\n> all our concerns, and we may well move to git sooner rather than later\n> now!\n\nYou're welcome. You just seemed to be under some misapprehension.\nGit can certainly do all the basic things that svn does, and just\nas easily.\n\nYou'll only have to learn more because you'll want to do more.\n\nThere are three big things that you'll want to get used to\nwhen coming from CVS or any other centralized version system:\n\n1) Don't blink, you might miss it. If you're used to CVS, you might\n wonder whether git actually *did* anything. Commits, in particular,\n are instantaneous if the necessary data is cached in RAM, and it can\n take a while to learn to trust that everything worked.\n\n2) Commits can be undone. It can be a bit scary the way a command\n like git-rebase will make a whole bunch if repository changes and\n then maybe get stuck with a patch conflict. You want to be\n comfortable undoing things, or amending commits if you're\n not happy with what happened.\n\n This is why novices (and I used to be one) are reassured by the\n existence of \"git merge --no-commit\", but experienced users don't\n see the point.\n\n With git, pushing (or asking someone else to pull) is the\n moment of truth. Committing has no lasting consequences.\n\n3) Branches are your friend. CVS users think branches are a big\n deal and require careful thought and planning. Git users branch\n almost as often as CVS users commit. A typical \"big change\"\n that might be a single commit in CVS would be a branch of\n several commits in git.\n\n In fact, a good piece of advice is to NEVER commit directly\n to your trunk (\"master\"). Do ALL development on branches, and\n merge them into the trunk.\n\n I cheat on that a lot, but I also know how to fix things if I get\n caught becauee a quick hack is proving not so quick: add a branch\n reference to the tip I'm developing on and then back up the master\n branch to where I should have left it when I started this project.\n"},{"id":"44372","messageId":"20070608204101.GA4084@efreet.light.src","threadId":"8478","inReplyTo":"20070607165150.27434.qmail@science.horizon.com","subject":"Re: Git Vs. Svn for a project which *must* distribute binaries too.","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2007-06-08T20:41:01Z","receivedAt":"2007-06-08T20:41:01Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Thu, Jun 07, 2007 at 12:51:50 -0400, linux@horizon.com wrote:\n> 3) Branches are your friend. CVS users think branches are a big\n> deal and require careful thought and planning. Git users branch\n> almost as often as CVS users commit. A typical \"big change\"\n> that might be a single commit in CVS would be a branch of\n> several commits in git.\n> \n> In fact, a good piece of advice is to NEVER commit directly\n> to your trunk (\"master\"). Do ALL development on branches, and\n> merge them into the trunk.\n> \n> I cheat on that a lot, but I also know how to fix things if I get\n> caught becauee a quick hack is proving not so quick: add a branch\n> reference to the tip I'm developing on and then back up the master\n> branch to where I should have left it when I started this project.\n\nThere is a big difference between the cvs and subversion notion of branches\nand the git one, which make branches so much more friendly in git.\n\nIn cvs and subversion, branch name is part of the commit identity, so you\nhave to create it before you commit and it will stay with you forever. That\nmeans you have to plan the branch, because there's no going back.\n\nOn the other hand git branch (head) names are just pointers to revisions you\nbase your work on. You can add branch name after you commit, you can rename\nthe branch anytime and you can delete branches that are no longer\ninteresting, either because they are already merged, or because they didn't\nwork out. That means you don't have to think twice whether you need a branch\nbefore you commit, since you can always change your mind later.\n\nThis makes it possible to use heaps of short-lived branches for\nexperimenting and to give them silly names, because noone cares if you don't\npublish them, which you don't need to do and ususally won't do until you are\nconfident that you are working in the right direction (at which point you\nhave much better idea about what name to publish them under).\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec \n"}]}