On Tue, 2 Aug 2011 11:35:30 -0700 (PDT) Redeux <redeu...@gmail.com> wrote:
> Hello, i have Problems understanding the basic idea behind DVCS. > > In CVCS you commit into central repository, which is up-to-date. > > In DVCS you use a local repository for commit. If other developers > want to use your data, they have to pull the data from your repository > or from a central repository. > I have problems understanding the advantage, because if you want to > have the actual data, it produces extra work. > They have to pull data from every developer whos data they are using > or every developer has to push into central repository (that means > they have to commit AND push). > > For example, A, B and C are working together on a software project. If > A wants to have the actual data, he has to pull the data from B and C. > And if they use central repository B and C have to push into central > repository (after every commit to guarantee that the central > repository is up to date) and A has to pull the data from central > repository. > > Using a CVCS results in simple committing and update? > > Am I right or is there anything i misunderstood? While Thomas already cleared up some of the points, I'd like to add. First, the word "distributed" routinely provides certain misconseption among people first looking at the thing because they tend to imply you're somehow forced to go distributed. This is simply not true: if your team of N people uses a DVCS for development, this does not mean everyone in the team has to set up N-1 links with the other members of the team--you can happily use a centralized "reference" repository everyone pushes to and effectively have a "star" linking scheme as with CVCS. In reality, the "distributed" term refers to a neat property of these systems: instead of using abstract "versioning" on files or whole repositories (cf. CVS and SVN) they use the concept of unique identifiers on commits (snapshots of the whole repository state) and objects these commits refer to. This allows minimal selective transfers of required lines of development from one repository to another. To understand the idea, it's best to start from reading "The Git Parable" [1] which explains this in the simplest way possible. Second, while DVCSes indeed differentiate between committing and pushing your changes, there are two points to be made: 1) That way of operation is not necessarily cast in stone. For instance, cool little Fossil [2] by default works in the so-called "autosync" mode, in which before each commit, an attempt to fetch is performed to see if our leaf diverged from its "remote" version, and after each commit an automatic push is performed. So it basically works no different from Subversion. This can be turned on or off anytime. Git, to my knowledge does not have built-in support for such kind of thing but I suspect it either can be emulated or at least some working policy could be adopted. 2) I think the fear of needing to manually push what has been committed is mostly rooted in the CVCS-incurred mindset in which you do lumpy gross commits implementing big changes--simply because it's hard to do it another way. In Git, you have tools to make small, atomic, incremental commits, implementing changes which are small, localized in space and/or thought process. Hence, when in a CVCS you would have one big commit, in Git that same changeset would consist of several commits. Suddenly, separation between committing and pushing starts to make sense: you're pushing *series* of changes implementing features (or fixing bugs or whatever), not mere commits. This makes even more sense after your read about history re-writing which allows you to first hack a series of not so beautiful commits and then transform it to something more digestible by peer reviewers and then push this prettified series throwing away the original one. 1. http://tom.preston-werner.com/2009/05/19/the-git-parable.html 2. http://www.fossil-scm.org -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
