3

I have really tried to understand how distributed version control systems alter the way we work. I watched a tech talk of Linus Torvalds on git, which is mostly about the power of distributed version control, and he claims that it alters the way in which we work.

Let's consider git. There are plenty of good reasons to love and use git, I am aware of these good reasons. I am also certain that the power of the decentralised model doesn't extend to just efficiency and the ability to make local commits. One of the important points is that it allows developers to synchronise their work. Assuming that the work has not been commited already, I would presume the code to be (potentially) unsuitable for deployment, possibly subject to change (bad if I am hard coupling my dependencies to it), which to me sounds like a world of pain waiting to unfold.

I have a feeling that the decentralised model works brilliantly in the setup that Linus faces, but this is typically uncommon of most setups or needs, and that a centralised setup is essentially what we all want and use within our unified networks (i.e. the majority of company setups, though I admit this is an assumption on my part). We all push stuff back to a central location so we can share it with others, and this need for centralisation forms the basis of github. We all rely on the integrity of the central location to provide secure access to our work and to back it up for us as well.

Don't regress into answering why git is lovely. It works brilliantly in a centralised model with the bonus of local commits, but I really feel like I have missed the point about decentralised workflows somewhere.... I may have to watch the video again

Update:

Thanks for engaging the question, I don't think I made my point particularly obvious. Basically the issue I face is as follows. Many companies are setup with a central workflow. We work on a unified fast local network. Managing the logistics of a centrally managed configuration are somewhat simpler; we all use the central repository, this is the honey pot we make sure to safeguard against disk failures and fires and anything else you might be paranoid about. Factoring this necessity into your workflow increases the chances that your work, regardless of state, ends up in this safe location. We rely on the network connectivity and availability of this central location for just about everything we share. I first thought that maybe that our love for the central workflow is just our inability to grasp how to use DVCS on the micro scale. Now to say just use git because it's a superset of the centralised variant is ok I guess. However given that I still, in the majority of cases, can't see anything that is intrinsic to the decentralised model, we might be using a more complicated tool to solve a simpler problem. There may be some value in a centralised tool that does what we are already doing.

Matt Esch
  • 22,661
  • 8
  • 53
  • 51
  • 1
    See also http://stackoverflow.com/questions/2704996/describe-your-workflow-of-using-version-control-vcs-or-dvcs, http://stackoverflow.com/questions/2563836/sell-me-distributed-revision-control/2563917#2563917 and http://stackoverflow.com/a/2473315/6309 – VonC Mar 01 '12 at 22:37

5 Answers5

3

Git improves workflow because merges are no longer painful things to do.

If you've ever worked with several developers on a single project using a SCM, you should know that merging is THE #1 issue you have to deal with. Assuming you watched the video, you already know that Linus went to some lengths to elaborate on that issue, and why that is the main issue with other SCMs.

I'm going to be restating the example Linus made in the video you said you watched, but here goes:

Say there are 3 developers, including yourself, working on a project that has 3 parts. You are all experts in respect to the parts you're working on. Assuming you've been designated the maintainer of the repository, the other two developers may ask you to merge code into the main branch. BUT! You're not an expert on what they worked on, and you don't necessarily need to understand how their code works... but you trust that the changes they've made are OK. With git, you can shift the responsibility (read: work) of merging to them. Once they've pulled your code, merged theirs into it, and committed it, they can ask you to pull the merged code.

Why is this good? Because they did all the work, and they understood what they were merging. Without git, this process would undoubtedly be very painful and time consuming.

Brendan
  • 4,565
  • 1
  • 24
  • 39
  • I almost asked why can we only have this with a distributed model? Is this not simply an elaborate branch merging feature? What you are simply saying is, I can't merge my branch into your new code. Please merge these. But it's pretty obvious why this isn't the same thing. Cloning a repository is much cleaner than leaking all over a repository with branches (no access required). But what I would like to do is to find out if there is any use to DVCS in your average software company. I have only ever worked in an environment where we each have equal responsibility for maintaining the repository. – Matt Esch Mar 02 '12 at 00:25
  • -1, because 1. Natural merges **isn't exclusive Git** feature 2. Merge **doesn't correlate** directly or indirectly to *DVCS nature* of VCSes. FAIL! – Lazy Badger Mar 02 '12 at 06:04
  • Yes, others have them as well, but merging is EASY with DVCS because you don't have the same hierarchy as you do in a CVCS. The point is that you can merge OFTEN with a DVCS which makes it nearly painless. The same can not be said about CVCSes. – Brendan Mar 02 '12 at 15:46
  • I **can** (and **do**) "often merge" in SVN. Really, I merge **every** trunk-revision in my branch. Natural merge in Git|Mercurial|Bazaar|etc have **another source, unrelated to distributed form** – Lazy Badger Mar 05 '12 at 18:33
2

DVCS allows you to do stuff without affecting other people's work until it is ready to.

So you can fix all your mistakes and integration incompatibilities locally, then send it out.

Paul Nathan
  • 39,638
  • 28
  • 112
  • 212
  • 1
    And my own branch in subversion is incapable of this? I can fix my problems locally in a checkout of my own branch. I already admitted that I can't commit locally, but I can commit back to my own branch at the central location where people can potentially access it. Most companies are fortunate enough to have a fast local network so the issue of unavailable central repositories or slow access should not be an issue in the majority of cases. – Matt Esch Mar 02 '12 at 00:10
  • Some developers may not like switching between branches (may have trouble) but push to / pull from to different remotes (fork) is easier – linquize Mar 02 '12 at 03:51
  • 1
    @me232: yeah, it's nice being able to revert your local commits if things go sour..... – Paul Nathan Mar 02 '12 at 07:05
  • @MattEsch Your own branch in Subversion still lives in the same repository as everyone else’s, and merging it back into trunk (when the time comes) will be tedious because of SVN’s poor merge support. In a DVCS such as Git, your own branch can live wherever you want it to, and merges are easy. (There’s no intrinsic reason that merging *couldn’t* be easy in a CVCS, but I don’t know of any where that’s actually the case.) – Marnen Laibow-Koser Jun 01 '18 at 02:52
2

I'll try to answer on asked question

Sort version

Any DVCS does NOT improve workflow by itself. So on question "How?" fast&simple answer is "In no way!"

Longer version

DVCSes have possibilities (due to distributed nature), which can be used to change and evolution workflow and common style of work. But it's always not technical, but managerial, administrative and organizational solution and responsibility: what, how, when, to solve which business-tasks using DVCS is possible and justified.

Immediately at the start I can see one big business advantage of DVCS - it allow P2P communication between developers, decreasing this way wasted in CVCS mode time.

Where it can be useful and requested? Any time, when 2+ developers work on related, but isolated from "mainstream" task. Imagine

  • some system with core and frontend and separated responsibility areas (coredev doesn't touch frontend, frontman can't do any with core)
  • one repo for core and front, without external repos (all-in-one)
  • small job in front require core changes
  • front-file is in /views/default/main/lib.js, core-file /core/db/connectors/engine (but locations deep haven't real value in our example)

SVN-version, branch-per-operation mode

  • Frontman works with WC, related to branch "branches/lib2-frontend" (not sparse copy), when "shit happens"
  • Coredev create branch "branches/lib2-fixes", successfully perform changes, commit
  • Frontman monitor repo and wait final commits from Coredev
  • Frontman have to get somehow updated files for his job and. Start mergevoodoo magic
  • If all is OK, frontman have to eliminate some way commiting merged from coredev core-file in his commit

DVCS-version

Story is not dramatically shorter and differ in 1 place - when coredev have his finished job, branch delivered to frontman, merged locally. Later merged work can be branched-cleaned-stripped into ready to publish for public form (cherry-picking, history rewrite etc)

Lazy Badger
  • 94,711
  • 9
  • 78
  • 110
  • In case of DVCS-story I (as Mercurial and MQ evangelist) instead of commit may prefer direct exchange of MQ-queues and don't touch repo with new changeset while it isn't really needed at the end of story - and MQ is a lot more usable, than ordinary patches – Lazy Badger Mar 02 '12 at 06:59
  • I think this answer addresses my question in the most appropriate way. I should also add there are even simple benefits to this distributed model, such as if someone wants to see the state of my current in-progress work they can just grab it from me. I do think there is space for innovation in purely central version control systems, it's just a case of identifying the benefits of the DVCSs and seeing if we can achieve similar benefits under the simpler model. – Matt Esch Mar 05 '12 at 18:11
1

I really feel like I have missed the point about decentralised workflows

Wherever I've used Git, both personally(Github) and at $work, it's mainly a centralized model. However, the only advantage I see with the decentralized model is speed. I'm pretty sure it is way faster to commit a few times during the day locally and then trigger a push to the central repo at the end of the day. Compare that (speed) to making multiple commits to a remote repository everyday.

mithun
  • 316
  • 3
  • 3
0

I'm confused, what is it you're trying to understand here? You essentially say "I know why git is great", then proceed to ask "why is git great?" This has the feeling of not really being a question, or at least a question that is rather ambiguous in what is being asked for.

If you're asking specifically how a DVCS improves workflow, then I'd say it does in that every user has their own copy of the repository, and as such can work completely independently, but still retain the ability to merge back with others working on the same repository.

Ex: say Joe is working on "project A", and I am also working on project A. Joe & I can go crazy, doing commits, refactoring, etc, etc, but at the end of the day still combine our code (this is essentially the model of Github -- you fork a project, do crazy stuff, but because your copy is a clone of the original, it's always possible to easily merge your changes back into the original).

But I feel that I've missed what it is you're asking.

You might perhaps also wish to take a look at Version Control By Example which is a free e-book that discusses some various pros and cons of different DVCS's (git just being one). Perhaps the answer you seek is in there.

Adam Parkin
  • 17,891
  • 17
  • 66
  • 87
  • 1
    Git is great. If you use git in a centralised way, it still competes with and defeats many central version control systems in terms of performance. But this does not reflect upon the distributed nature of git. A CVCS could be conceived with the same benefits. What I really want to understand is how the distributed feature of git really changes the way we work, because it seems that what git users want to do is to share their repos through a centrally stored location anyway. The same workflow could be achieved with a CVCS with branching. I will take a look at that ebook you linked, thanks. – Matt Esch Mar 01 '12 at 23:40
  • To give a better commentary of what I actually say, 'You essentially say "I know why git is great", then proceed to ask ...' *why is DVCS great*? I don't think DVCS is the reason why git is great, or at least I can't see why DVCS makes git great. But I see why data integrity and speed makes git great. Is bazaar great for supporting the distributed model? I just wonder if there is more greatness to be found in git or any DVCS if we change the way we treat it, but I suspect it is only really useful in epic problems where work is naturally widely distributed (like the linux kernel project) – Matt Esch Mar 01 '12 at 23:59