When will CVS be replaced by modern version control system?

Josh Boyer jwboyer at gmail.com
Sat Nov 10 16:31:47 UTC 2007


On Sat, 10 Nov 2007 10:42:45 -0500
Jesse Keating <jkeating at j2solutions.net> wrote:

> On Sat, 10 Nov 2007 14:10:38 +0100
> Nils Philippsen <nphilipp at redhat.com> wrote:
> 
> > > a) quick operations by avoiding round-trips to a remote server if
> > > not necessary
> > > b) easy branching and merging
> > > c) atomic operations
> > > d) co-maintainers (or maintainer apprentices) wouldn't need commit
> > > access to the main repository
> > > e) ability to do embargoed stuff like security fixes before they're
> > > public  
> > 
> > f) ability to rename things, especially handy for re-worked patches in
> > our context
> 
> I don't disagree that those things are nice with DVCS.  What I question
> is the amount of times they're necessary to warrant the extra
> complexity of a DVCS thrown at every user.
> 
> And still I continue to hear just features of dvcs, but not applied to
> a workflow for our Package vcs.

I think it's because you have two classes of users.  Developers, and
packagers.

There are several people that are active developers for the packages
they maintain.  They're used to working on the code base itself,
developing patches, etc.  RPM specfiles are almost the last step in
their day-to-day dealings with a package.  These are the people that
are the major proponents of a DVCS.

Then there are the packagers.  They mostly take the upstream tarballs,
do the specfile work, and build things.  There isn't a lot of need for
multiple commits, offline working, etc.  The entire VCS setup we
currently use is geared toward packagers.

josh




More information about the fedora-devel-list mailing list