Re: What a modern collaboration toolkit looks like

["Óscar Fuentes" <ofv@wanadoo.es>]

Richard Stallman <rms@gnu.org> writes:

>     So perhaps you hack all day, periodically making commits (using "git
>     commit") which store your changes into the .git subdir.  Then when you
>     later connect to the net, you can merge the new changes in .git into the
>     remote emacs repository on savannah (using "git push").
>
> It sounds like "git push" is the real analogue of CVS commit,
> and that this is the closest match-up between the concepts of git
> and the concepts of CVS:
>
>    	  CVS           GIT
> 	  save file  =  commit
> 	  commit     =  pull or push
>
> But I still don't understand what step actually alters the trunk that
> users will get by default from the public repository.  Does `push' do
> that?  If not `push', then what?

The basis of DVCSs is that every user has one (or more) personal
repositories. You work on your own for a period of time as if you were
the only one on the project, committing changes to your
repository. Then, you decide to share your changes with the rest of the
world. For this, you "push" the changes to the "golden" central
repository, where other users "pull" them to update their personal
repositories.

It's just a matter of independent repositories that communicates with
each other. "Push" is "send my changes" and "pull" is "get other's
changes".

Using analogies with CVS here is dangerous and only help to obscure what
a DVCS is. As is the case with learning a new programming language, it's
better to forget about specific languages you know and think on terms of
how useful the language is for you. Often you see that the new language
is a big improvement because it solves a problem that you didn't
realized until you see it solved.

A very important feature is that you are not limited to communicate with
the central repository. You can make available your personal repository
to other users and so create groups of developers working together on a
issue. When the work is done, some of you push the final result into the
central repository.

Personal repositories and peer-to-peer sharing opens lots of
possibilities: you can work on a difficult issue using localy the
advantages of having a personal VCS, doing multiple commits as you hack
the problem and, finally, "pushing" to the central repository the clean,
finished work. As mentioned above, you can share your changes with other
people without touching the central repository. You can create as much
personal branches as needed for your personal use, as this is a local
operation. In fact, some DVCS encourage branching even to implement
almost trivial changes, which makes much sense if you ever work on more
than one issue at the same time.

When your repository communicates with other repo, either by getting
(pulling) or by sending (pushing) changesets, a merge is
performed. DVCSs uses sophisticated algorithms for tracking merges and
remembers which changesets are already merged on every repository. It is
possible to get or send a selection of changesets on a consistent way
(this is termed cherry-picking), that is, if you require changeset 100
and it depends on changeset 93, the system knows this and takes the
appropiate action.

-- 
Oscar