Home/ Questions/Q 3605646
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-18T21:09:00+00:00

The question An open source program uses CVS for version control. I would like

  • 0

The question

An open source program uses CVS for version control. I would like to make a number of bug-fixes and submit patch bombs to the developers with commit access. I would also like to maintain my own semi-private fork that mainly tracks the main code-base but that includes my own features (these features, right now, should not be incorporated into the main code-base.)

I prefer to use mercurial for my own version control needs, but I am open to other version control systems if necessary.

I’d like to:

  1. Be able to easily create patch-bombs against the current CVS source with my own bug-fixes
  2. Keep track of history on my own features
  3. Have fixes and improvements from the main tree easily incorporated in my new-feature fork
  4. Easily apply my own bug-fixes to my new-feature fork
  5. Be able to work and track change history without an Internet connection.

What suggestions do you have for doing this?

My current idea

My own best guess is below, to give you a better idea of what I am thinking about.

I will have 3 mercurial repositories.

The first two repos are managed as specified at (https://wiki.mozilla.org/Using_Mercurial_locally_with_CVS). One just mirrors the latest changes from the CVS upstream. I do “cvs update” then “hg commit” in this repo. The second repo holds my bug-fixes as patches using the mq extension and I pull from the the first repo and re-base my patches every so often. When my patches are incorporated into the main tree, I remove the patches from the patch queue/make them permanent commits.

The third repo is my local fork. It will start out as a clone of the first repo. Then each time I do an update of the first repo, I’ll pull from it into repo 3. My own features will be directly present as commits in this repo. When I fix a bug, I’ll export a patch from repo 2 and apply it to the appropriate pull from repo 1.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I have used Git to manage changes on top of a CVS repository in a similar way. My solution in Git uses local branches instead of multiple repositories, but it sounds essentially similar to your proposed idea.

    I found that this arrangement works best if you commit all the CVS metadata (in the CVS/) subdirectories) to your mirrored repository. This means that the CVS metadata gets replicated in the other repositories, but it doesn’t cause any harm (and lets you run commands like cvs diff if you need to).

    • 0