<story><title>Abandon your DVCS and return to sanity</title><url>http://bitquabit.com/post/unorthodocs-abandon-your-dvcs-and-return-to-sanity#</url></story><parent_chain><item><author>Xylakant</author><text>&amp;gt;  Anyone else remember the days when having your SVN server go down meant that you more or less had to wait until the server came back up before you could get back to doing things? (if you wanted a nice atomic commit).&lt;p&gt;That&amp;#x27;s now known as &amp;quot;I can&amp;#x27;t deploy because github is down&amp;quot;. Note that the author proposes &amp;quot;local commits plus a centralized storage&amp;quot;.&lt;p&gt;&amp;gt; The author mentions that you have to retain the whole history of a project. For one thing, storage is cheap.&lt;p&gt;Not in portable computers. I can get a TB, but that&amp;#x27;s it. I have build artifacts that clock in at about 300 - 500 MB and I&amp;#x27;d version control them if possible. I can&amp;#x27;t, because that would fill my disk within a couple of month, so I have to push them to a server and somehow link them.&lt;p&gt;&amp;gt; Anyone else ever needed their own fork of something due to differing goals from the parent project, but needed to fold in upstream changes relatively often? That&amp;#x27;s by nature the sort of problem that a DVCS solves easily.&lt;p&gt;That&amp;#x27;s a strawman. The article does not argue that there&amp;#x27;s no use-case that&amp;#x27;s solved by git or and DVCS. It&amp;#x27;s just that not every use-case is solved by git. I&amp;#x27;d even go out and argue that most use-cases are solved just as good by a solid centralized system with less complexity involved.&lt;p&gt;&amp;gt;  Just because we haven&amp;#x27;t had tools in this space with wide adoption that are user friendly doesn&amp;#x27;t mean that we won&amp;#x27;t eventually.&lt;p&gt;I see a developer wedge his git repo with a pull + rebase about once a month. And then somebody needs to walk over and explain. DVCS fundamentally introduce complexity that is not always needed. And I doubt that the fundamental complexity can be abstracted away.</text></item><item><author>iand675</author><text>Anyone else remember the days when having your SVN server go down meant that you more or less had to wait until the server came back up before you could get back to doing things? (if you wanted a nice atomic commit). Let&amp;#x27;s not forget people that have to travel a lot for work– SVN + airplanes is a match made in hell.&lt;p&gt;Anyone else ever had someone delete or close an open source project that you cared about? Finding a copy with the history that mattered to you could be tricky.&lt;p&gt;Anyone else ever needed their own fork of something due to differing goals from the parent project, but needed to fold in  upstream changes relatively often? That&amp;#x27;s by nature the sort of problem that a DVCS solves easily.&lt;p&gt;Other objections to this article:&lt;p&gt;* Nothing precludes you from using the patch model with DVCS (I mean, Linux kernel development uses Git just fine with this)&lt;p&gt;* The author mentions that you have to retain the whole history of a project. For one thing, storage is cheap. Another point worth mentioning is that you can make shallow clones with Git. I don&amp;#x27;t know what the status is for committing to them these days, but there&amp;#x27;s nothing fundamental that should prevent a DVCS from letting you work on shallow clones if space is such a big deal.&lt;p&gt;I could go on, but the article seems to be griping about UX issues. Just because we haven&amp;#x27;t had tools in this space with wide adoption that are user friendly doesn&amp;#x27;t mean that we won&amp;#x27;t eventually.</text></item></parent_chain><comment><author>jimktrains2</author><text>&amp;gt; That&amp;#x27;s now known as &amp;quot;I can&amp;#x27;t deploy because github is down&amp;quot;. Note that the author proposes &amp;quot;local commits plus a centralized storage&amp;quot;.&lt;p&gt;And in that cause you can scp your repo somewhere and change your origin and move on.&lt;p&gt;Also, do people really rely on 3rd party services for their deployed code?  I&amp;#x27;ve used github as a repo and colab tool at companies, but we still deployed from repos owned by the company.&lt;p&gt;&amp;gt;  I&amp;#x27;d even go out and argue that most use-cases are solved just as good by a solid centralized system with less complexity involved.&lt;p&gt;I&amp;#x27;d go out an argue that because the added complexity of git is far outweighed by the benefits of a local repo.</text></comment>
<story><title>Abandon your DVCS and return to sanity</title><url>http://bitquabit.com/post/unorthodocs-abandon-your-dvcs-and-return-to-sanity#</url></story><parent_chain><item><author>Xylakant</author><text>&amp;gt;  Anyone else remember the days when having your SVN server go down meant that you more or less had to wait until the server came back up before you could get back to doing things? (if you wanted a nice atomic commit).&lt;p&gt;That&amp;#x27;s now known as &amp;quot;I can&amp;#x27;t deploy because github is down&amp;quot;. Note that the author proposes &amp;quot;local commits plus a centralized storage&amp;quot;.&lt;p&gt;&amp;gt; The author mentions that you have to retain the whole history of a project. For one thing, storage is cheap.&lt;p&gt;Not in portable computers. I can get a TB, but that&amp;#x27;s it. I have build artifacts that clock in at about 300 - 500 MB and I&amp;#x27;d version control them if possible. I can&amp;#x27;t, because that would fill my disk within a couple of month, so I have to push them to a server and somehow link them.&lt;p&gt;&amp;gt; Anyone else ever needed their own fork of something due to differing goals from the parent project, but needed to fold in upstream changes relatively often? That&amp;#x27;s by nature the sort of problem that a DVCS solves easily.&lt;p&gt;That&amp;#x27;s a strawman. The article does not argue that there&amp;#x27;s no use-case that&amp;#x27;s solved by git or and DVCS. It&amp;#x27;s just that not every use-case is solved by git. I&amp;#x27;d even go out and argue that most use-cases are solved just as good by a solid centralized system with less complexity involved.&lt;p&gt;&amp;gt;  Just because we haven&amp;#x27;t had tools in this space with wide adoption that are user friendly doesn&amp;#x27;t mean that we won&amp;#x27;t eventually.&lt;p&gt;I see a developer wedge his git repo with a pull + rebase about once a month. And then somebody needs to walk over and explain. DVCS fundamentally introduce complexity that is not always needed. And I doubt that the fundamental complexity can be abstracted away.</text></item><item><author>iand675</author><text>Anyone else remember the days when having your SVN server go down meant that you more or less had to wait until the server came back up before you could get back to doing things? (if you wanted a nice atomic commit). Let&amp;#x27;s not forget people that have to travel a lot for work– SVN + airplanes is a match made in hell.&lt;p&gt;Anyone else ever had someone delete or close an open source project that you cared about? Finding a copy with the history that mattered to you could be tricky.&lt;p&gt;Anyone else ever needed their own fork of something due to differing goals from the parent project, but needed to fold in  upstream changes relatively often? That&amp;#x27;s by nature the sort of problem that a DVCS solves easily.&lt;p&gt;Other objections to this article:&lt;p&gt;* Nothing precludes you from using the patch model with DVCS (I mean, Linux kernel development uses Git just fine with this)&lt;p&gt;* The author mentions that you have to retain the whole history of a project. For one thing, storage is cheap. Another point worth mentioning is that you can make shallow clones with Git. I don&amp;#x27;t know what the status is for committing to them these days, but there&amp;#x27;s nothing fundamental that should prevent a DVCS from letting you work on shallow clones if space is such a big deal.&lt;p&gt;I could go on, but the article seems to be griping about UX issues. Just because we haven&amp;#x27;t had tools in this space with wide adoption that are user friendly doesn&amp;#x27;t mean that we won&amp;#x27;t eventually.</text></item></parent_chain><comment><author>iand675</author><text>&amp;gt; Not in portable computers. I can get a TB, but that&amp;#x27;s it. I have build artifacts that clock in at about 300 - 500 MB and I&amp;#x27;d version control them if possible. I can&amp;#x27;t, because that would fill my disk within a couple of month, so I have to push them to a server and somehow link them.&lt;p&gt;git-annex is a pretty good solution for this: &lt;a href=&quot;https://git-annex.branchable.com/&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;git-annex.branchable.com&amp;#x2F;&lt;/a&gt;&lt;p&gt;&amp;gt; That&amp;#x27;s a strawman. The article does not argue that there&amp;#x27;s no use-case that&amp;#x27;s solved by git or and DVCS. It&amp;#x27;s just that not every use-case is solved by git. I&amp;#x27;d even go out and argue that most use-cases are solved just as good by a solid centralized system with less complexity involved.&lt;p&gt;I&amp;#x27;m not convinced that it is a strawman– I&amp;#x27;m not an uber-developer, but I&amp;#x27;ve had to do it reasonably often. A common case is that the originator loses interest, and you still need to do maintenance on it. I&amp;#x27;d rather my go-to choice of a version control system support that notion rather than learn a different tool to deal with this case.&lt;p&gt;&amp;gt; I see a developer wedge his git repo with a pull + rebase about once a month. And then somebody needs to walk over and explain. DVCS fundamentally introduce complexity that is not always needed. And I doubt that the fundamental complexity can be abstracted away.&lt;p&gt;Sure, there is an additional level of abstraction, but to argue that it&amp;#x27;s insurmountable seems rather pessimistic. Most technologies that we take for granted now required multiple decades to get to a consumer-friendly state. This is perhaps a philosophical difference that only time will answer.</text></comment>