When will be CVS replaced by modern version control system?

[Lennert Buytenhek]

On Fri, Nov 09, 2007 at 10:52:30AM +0100, Karel Zak wrote:

> > And sure it is not very convenient for developpers, because
> > developpers typically do not want to think about this stuff and would
> > be happy to have their IDE directly plugged into production or user
> > systems. But that's basic maintenance discipline that makes everyone
> > else's life easier.
> 
> I think the best way (for Fedora project) is Tom Mraz's suggestion:
> use stupid central CVS as a storage for patch files and locally use
> scripts that convert these patches as code to/from real DVCS.

I've been doing something like that, but only for the packaging
(i.e. no exploded trees.)  I have a local CVS->git conversion of the
Fedora CVS tree which I use for things like:

1. Being able to quickly see the history of a package and changes
   between packaging in different versions of that package without
   having to go through the CVS server (which is on another
   continent than the one I am on -- I guess the latency from the US
   is probably not too bad.)

2. Visualising branches with gitk, to make it easier to see where
   F-7/F-8 branches have forked off from devel, etc.

3. Maintaining trivial patches for the ARM port such as the one in
   BZ#245441 (when a new upstream release comes out, just run 'git
   pull' and be done.)

4. Maintaining not-so-trivial patches, such as patches to make
   packages build cross, or patches to make packages build with
   uClibc instead of glibc.


There are a number of observations to be made about keeping local
changes to packages:

- For patches in category (3), you could argue that these should
  just be merged upstream, and that would remove the need to make
  maintainance of separate patches easier.

  The truth is that they aren't always merged quickly, and giving
  arch teams unrestricted CVS access only solves part of the problem
  (e.g. what if you want to commit a patch that solves an issue but
  you're not sure whether the maintainer will like it, but he
  isn't responding -- you'll still have to maintain the patches
  separately somehow for some time.)

- Also, the patches in category (4) are unlikely to be merged into
  Fedora any time soon, and the "We can stick with CVS because we
  don't have to make life easier for forks because those people
  should just be working on upstream Fedora instead" argument doesn't
  really apply, because we have enough local changes that you wouldn't
  even _want_ to have in Fedora. ;-)

- Besides, the existence of OLPC-2 branches for various packages
  suggests that we _do_ want to accommodate forks to a limited
  extent.

  Note that in a distributed VCS, the OLPC-2 specific stuff wouldn't
  have to live on the main Fedora VCS server, and could very easily
  live on a separate box.  (Whether this is desirable for the OLPC-2
  stuff or not is a separate issue, I'm just saying that it is easily
  possible in a DVCS.)  (And whether the result can still be called
  Fedora or not is also a separate issue.)

- [ Also, putting our cross/uClibc patches in a VCS that understands
    branches makes it easier for us to keep those sets of patches on
    different branches, i.e. keep them separate, and only merge them
    the moment you want to build a package.          ]

If you have a need to maintain local changes to packages, IMHO
you're _much_ better off if you keep them in a VCS that is connected
to the upstream Fedora VCS in some sense.

I _could_ just have checked out Fedora CVS, committed that into my
own CVS tree, and started hacking on that, but then I would just be
making life a lot harder for myself, as that would make pulling in
new upstream changes hell, and would probably lead to a permanent
fork.


As an example, Fedora's rpm packaging looks somewhat like this in
gitweb:

	http://git.wantstofly.org/?p=fedora/rpm.git;a=summary

The tags in the upper half correspond with tags in CVS.  The heads
on the bottom correspond with each of the branches in CVS -- note
how that in the git conversion, different branches live in one
repository, and are merely different versions of the same thing,
instead of living in separate subdirectories in the same module.

To see the individual commits, click on 'shortlog' next to the
branch name (under 'heads'.)

In gitk, it ends up looking something like this:

	http://www.wantstofly.org/~buytenh/fedora-git-rpm.png

Note that it is really easy to see:
- where F-7/F-8 forked off from devel
- whether there have been patches applied to F-7 or F-8 that
  haven't been committed to devel yet or vice versa
- etc.

Two more examples (gcc and glibc) are here:
	http://git.wantstofly.org/?p=fedora/gcc.git;a=summary
	http://git.wantstofly.org/?p=fedora/glibc.git;a=summary