Re: CVS bashing?

[Paul Sander]

It could be better in lots of ways.  Here are three:

- If a branch is merged multiple times to an ancestor, don't count the
  result of the prior merge as a conflict.  (Remember, CVS performs a
  3-way merge, which is essentially to apply the difference between a
  common ancestor and a contributor to the other contributor.  The
  selection of the common ancestor is primitive:  It's the branch point
  where the to contributors' branches diverged.  So, for every merge,
  the result of every prior merge shows up as a difference between each
  contributor and the common ancestor, which is by RCS' definition a
  conflict.)
- Invoke a type-specific merge tool, ideally one of the user's choice.
  This allows for an interactive merge using a more sophisticated GUI,
  which many users prefer over the ASCII-based mark-up method that CVS
  currently uses.
- Implicitly select the checked-in contributors of merges by timestamp,
  using the time at which the update command was given.  This alleviates
  locking conflicts during large merges.  (See the "rename atomicity"
  thread to find out why this is safe, because updates are read-only
  operations on the repository.)

--- Forwarded mail from address@hidden

> Merging is very primitive 

Hmmm.  How could it be better?  NOT a rhetorical question; I'd
really like to know.  (I haven't used the commercial ones he's
comparing CVS to.)

--- End of forwarded message from address@hidden