<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 28 Aug 2009, at 11:37, Dave Brotherstone wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div class="h5"><font class="Apple-style-span" color="#888888"><br></font>>> Ian Munday wrote:<br> >> Why Git? I'm familiar with CVS and Subversion, but doesn't Git<br> >> essentially provide the same functionality, albeit in a slightly<br> >> different way (local versus centralised repositories)?<br> >></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div class="h5">> David Goodwin wrote<br> ><br> > My understanding (I've never really used git) was that it handles<br> > branching and merging a lot better than subversion.<br> ><br> > I believe git can have a single centralised repository.<br> ><br><br></div></div></blockquote><div><br></div><div>Well, it can... but only because you deem one repository "special" / centralised.</div><div>Branching and merging is far easier, faster and more reliable in git. So good, in fact, that I (and many others) branch for any and every feature or bug fix. </div></div></blockquote><div><br></div><div>We do this with subversion at work. From a code and release organisation standpoint, branching for every feature/bug fix solves an awful lot of problems.</div><div><br></div><div>I have a situation that's similar to Ian's and use the same basic idea that Dave suggested here (though in subversion):</div><div><br></div><div> /trunk/</div><div> /branches/client1/</div><div> /branches/client2/</div><div><br></div><div>As everything is in one repository, it's easy enough to pull and push patches around, though made much easier if you keep track of the rv numbers, for when a client specific new feature doesn't go into trunk, but is needed for client 22. Also, it's wise to put the underlying library code into a separate repository and bring it in via svn:externals. This saves a boat-load of merging when you bug fix some underlying helper code :)</div><div><br></div><div><br></div><div>(Going off topic here)</div><div>I've never used it, but understand that git is much much faster for branching and merging which is nice. Personally, with my Tech Director's hat on, I'm concerned about four main things with git in terms of introducing to the company:</div><div> 1. The two-step process required to get a commit to the master server (git commit, git push). I'm especially worried that devs will commit and not push and have no idea how easy it is for them to see what they haven't pushed yet. (Of course, it may be easy to automate this for all I know!)</div><div> 2. Windows support is not a first class citizen</div><div> 3. Easy switching of a working copy to a different branch means more developer care needed to ensure on correct branch before coding</div><div> 4. Lack of GUI tools and integration</div><div><br></div><div>These are all work-around-able, of course - the question is whether the benefits of a faster merge is worth it when I don't need a distributed VCS and have to coerce it into a master VCS setup. Certainly if it was just me, then I'd consider it much more closely - especially if I had unreliable Internet connectivity :)</div><div><br></div><div><br></div><div>Regards,</div><div><br></div><div>Rob...</div><div><br></div><div><br></div></div></body></html>