[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] [Fwd: Service Update: CVS]

From: David Brown
Subject: Re: [Gnu-arch-users] [Fwd: Service Update: CVS]
Date: Sun, 21 Sep 2003 10:05:20 -0700
User-agent: Mutt/1.5.4i

On Sun, Sep 21, 2003 at 09:45:00AM -0700, Tom Lord wrote:

> "Trying to solve problems" glosses over the question of _which_
> problems and _why_those_ problems.   I don't see how "trying to solve
> a problem" rules out the presence of ego.

I think this really explains why the revision control projects out there
are so radically different.  Each is looking at a fairly different set
of problems to be solved, and focusing their efforts/design on those

- Subversion seems to be CVS users who are annoyed by some of the major
  problems with CVS.  They seem to be glossing over some other
  significant issues, such as merging.

- OpenCM seems to be focusing primarily upon security.  They also want
  distributed development, but give security higher priority.  None of
  the distributed development has been implemented.  They have put some
  work into merging.  They do keep track of merge history, and most
  repeated merges do work.  It doesn't have the flexibility of replay,

  One significant difference between OpenCM and Arch.  OpenCM has global
  archive and version identifiers, however they are large random
  strings.  This is certainly easy to do, but it can be very difficult
  to track down what a merge is actually against.

- Arch seems to be designed around Tom's careful analysis of what tools
  are needed for actualy development.  I think his model fits quite
  well.  Analyzing the large commercial project at work, I can see arch
  as the only one that would fit the development model we use.
  Currently we use Perforce, but not as much because Perforce handles
  these problems well, but because it is kind of a free-for-all system.

I haven't looked at the other projects, though.  Arch has certainly
gotten to the point of doing what I need.  With 'tla', the
implementation also performs quite well.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]