<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">On 30 Nov 2015, at 08:49, Hans Hübner <<a href="mailto:hans.huebner@gmail.com">hans.huebner@gmail.com</a>> wrote:<br><div><br class="Apple-interchange-newline"><blockquote type="cite"><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;">That said, I do think that git is much better than Subversion for its easy branching - Seeing Gary's "heads-up" messages when he starts some larger activity on the trunk is, while somewhat entertaining and "community building", also reminding me of days way back in the past, when everybody contended for the scarce disk space and servers. Nowadays, making a large chunk of work consisting of a multi-day effort available to the public is typically an atomic operation, where the programmer merges the branch back to the main line. From a technical perspective, I do believe that such an approach is better than emails telling people not to pull from upstream because upstream may be unstable.</span></blockquote></div><br><div>I realise that this is implicitly being rude about Gary's workflow, but there is no reason for this with SVN. Although I prefer git nowadays, at work I use a seriously huge SVN repo (tens of years worth of Fortran NWP model worked on by hundreds of people) and this never happens. The SVN solution to this is make changes in a branch, then iterate (merge out from trunk, check on the branch that it works, merge to trunk without committing) until the last merge is empty, commit to trunk. This is, in fact, identical to the git solution: make changes in (branch in) clone, then iterate (pull from origin, merge into clone's trunk, and push to origin) until the final push succeeds. (In both cases the iteration is needed in case other people have committed to the trunk after you merged/pulled it).</div><div><br></div><div>SVN's problem is nothing to do with merging or branching, it is the inability to work in a private clone. That means that all changes are as public as the repo, which means that people commit much less out of embarrassment, which in turn makes merging harder when they do commit.</div><div><br></div><div>My problem with GitHub is slightly different than yours. It very probably *will not exist* in ten years time in any recognisable way: that's fine for the git repos which will have other authoritative clones, but it's *not* fine for the metadata: all the issue tracking / wiki / blah stuff will just evaporate, because none of that lives in the repo (actually the wiki stuff can I think). Issue-tracking, for instance, actually matters, and I don'r want to lose all that history.</div><div><br></div><div>However this is probably not the forum for a git/SVN discussion, sorry to have further sidetracked things.</div></body></html>