[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: RFC: DOCPATCH: History of version control systems

From: Benjamin Pflugmann <benjamin-svn-dev_at_pflugmann.de>
Date: 2002-11-06 22:07:22 CET

Hi.

On Wed 2002-11-06 at 12:07:22 -0800, Zack Brown wrote:
> Hi folks,
>
> I thought it would be best to post something like this here for discussion
> instead of just committing it. It fills in the section in Chapter 1 of the
> book, dealing with the history of version control. It's not necessarily
> finished, but I wonder if I'm going in the right direction.
>
> Comments?

First, let me say, I like the direction. I really enjoyed reading it.

[...]
> + <para>To illustrate this situation, consider the situation in which
> + developer Q and developer R edit the same location of the same file. Q
> + checks the new file back into the repository without any problem,
> + because the changes map cleanly onto the file already existing in the
> + repository. However, when R attempts to submit changes to the same
> + file, suddenly the situation has changed. The file in the repository
> + is significantly different from the file R began to edit, and so R's
> + changes no longer map cleanly onto that file. CVS cannot fulfill R's
> + request, and instead informs R that there are conflicts between R's
> + version of the file, and the version in its repository. R then
> + compares the two files, identifies the incompatibilities, and
> + resubmits his work, taking account of Q's changes as well.</para>
> +
> + <para>while not perfect, this new situation at least allowed R to do
> + meaningful work, without waiting for Q.</para>

For my taste, that is a bit too theoretic for the history part. How
about giving Q and R real names, at least?

But, personally, I think that this kind of example is not needed in
such an overview at all. A deeper understanding of CVS's working is
not needed at this time, is it?

[...]
> + <para>These commercial <firstterm>version control systems</firstterm>
> + did more than just solve the problems of CVS. They radically changed
> + the way version control was handled. In the case of BitMover's
> + BitKeeper product, the entire idea of a central repository was
> + discarded in favor of a client-based system, in which each developer
> + kept a full repository on their own computer. This allowed a

You never mentioned that CVS repositories wouldn't be on their own
computer. I think you somewhere went from local to remote repositories
without explicitly mentioning this.

HTH,

        Benjamin.

  • application/pgp-signature attachment: stored
Received on Wed Nov 6 22:08:34 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.