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

Re: When will be CVS replaced by modern version control system?

On Wed, Nov 07, 2007 at 11:41:58AM -0600, Josh Boyer wrote:
> On Wed, 7 Nov 2007 15:12:45 +0100
> Adam Tkac <atkac redhat com> wrote:
> > Hi all,
> > 
> > CVS has already passed over best years. I'm wonder why modern
> > project like Fedora still has sources in this ancient system. Are here
> > any plans to replace it by git, mercurial, svn or other more modern
> > version control system?
> Replacing a VCS for the fun of it is pretty pointless.  Can you
> elaborate on a workflow you would like to see that CVS is not suited
> to?  Right now, CVS works fine for what we do, which is mostly editing
> spec files.
> I am by no means a proponent of CVS.  I think it sucks.  But we have no
> _usecase_ for a different VCS at the moment.
> josh

It's not replacement for fun. Yes, CVS works and I believe it will
work to end of universe. But question is if We have something better
than CVS. And We have. There're some common problems (yes, CVS and
SVN suffer :) )

- you have to keep huge changes on your machine when you're doing
  bigger patch. And it is really confusing sometimes
- you can't easily move source tree under development. When I want to
  do development on more machines I have to do ssh, diff, scp, patch. It's
  pretty annoying
- when you're doing on some feature you can't do on it simulateously
  with maintenance & bugfixing. You have to diff, save diff, fix bug,
  commit, dig your uncomplete "feature" patch, patch source and
  continue on development
- CVS server outage :)

all this common problems are solvable with CVS. But I know really better
workflows which cannot be used with CVS. Also I don't believe that
it's hard to switch from one VCS to other if We have arguments. Yes,
it will need some work like all improvements.


> -- 
> fedora-devel-list mailing list
> fedora-devel-list redhat com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list

Adam Tkac, Red Hat, Inc.

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