2

I'm curious what's the best practice of keeping your occasional contributions to an OSS project in git (e.g., on github/bitbucket/gitlab), whilst the upstream is exclusively CVS.

My take is that it's very convenient to simply commit CVS/{Entries,Repository,Root} directly into git, and then at any time and from any box, you can simply checkout your git repo (w/ git), and then update from the real upstream with cvs up, which is exactly what I do with my OpenBSD ports-readmes fork, as well as mdocml.

However, I've noticed that most people are quite surprised and puzzled to see these CVS files within these git repositories on my GitHub, supposedly thinking that it's some sort of an oversight on my part. Additionally, reyk's httpd, for example, doesn't have such a setup, either, even though he apparently usually updates it from upstream in bulk, without preserving the log from the upstream, either.

Am I missing something here? I feel like having CVS/{Entries,Repository,Root} within your git repository is a great idea, yet I've never seen anyone else doing it. Why?

Community
  • 1
  • 1
cnst
  • 25,870
  • 6
  • 90
  • 122
  • One rather large problem with committing your CVS metadata is that it is specific to you and your checkout out version. The way I have done it is to add `CVS` to `.gitignore`. That way I can still use both git and cvs and the rest of the world just uses git with no idea that there is a cvs repo involved. – Burhan Ali Jun 05 '16 at 16:31
  • @BurhanAli, no, that's the whole point of cvs -- the CVS metadata is NOT specific to me, but it IS specific to my checkout version, which is the whole point, because it's the exact same version that's committed to git. I cannot see any benefit whatsoever in adding the whole `CVS/` to `.gitignore`, because then the minute you clean up your local git checkout, CVS data will be irreparably gone. How's that better for anyone? If you don't believe me, try out http://github.com/cnst/mdocml, it should work as is with both git and cvs (after checking out with git first) on any modern system. – cnst Jun 05 '16 at 20:22
  • Maybe it's an artefact of how cvs is being used then. I used the `extssh` method and so my `Root` files contained something like `username@hostname:/repopath` which would not be useful to others. I also didn't delete the directory because I was always actively working on it. Just think carefully about whether these files are useful to others and whether or not their presence will cause confusion. – Burhan Ali Jun 08 '16 at 11:06
  • @BurhanAli, even if your `CVS/Root` has to contain a username, uploading `CVS/{Repository,Entries}` would still make it possible to quickly set up `Root` (either in the file, or through arguments to `cvs`, or through `env CVSROOT`), on the other hand, if the `Entries` file is missing, it'll be quite non-trivial to find the exact point in upstream that your downstream is based upon. – cnst Jun 08 '16 at 23:14

1 Answers1

1

I feel like having CVS/{Entries,Repository,Root} within your git repository is a great idea, yet I've never seen anyone else doing it. Why?

It seems a good idea, but it also mixup metadata (CVS reference) with data (your files of the repo).

That is why git-svn, for instance, do memorize that same kind of reference in git configuration (local config file, not part of the repo).
Anyone wanting to contribute to the upstream SVN repo need to to a git svn clone again.

An intermediate solution would be to explain in the README that a user need to create those CVS reference files once the repo is cloned, should he/she wishes to contribute back to (CVS) upstream.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Thing is -- git-cvs integration is rusty, so, mixing the old-style metadata with data seems like the best approach. And how would you even explain in README how to generate those `CVS` files? It's very non-trivial, as they have to reference the exact versions of what your repository is supposed to contain. – cnst Jun 02 '16 at 08:10
  • @cnst I agree, I was just trying to find an intermediate position, not suggesting to use git-cvs. I was using git-svn to illustrate why that kind of file is generally *not* in a git repo. – VonC Jun 02 '16 at 08:12
  • But I think that the intermediate solution you suggest is actually worse than any of the alternatives. Why even suggest it as a possibility, if it's not even doable per se? – cnst Jun 03 '16 at 21:44
  • @cnst Because normally, all this is managed by git-svn. If you don't have git-svn, you have to somehow explain what you want to do (ie, with your approach, explain why those CVS files are there) – VonC Jun 03 '16 at 21:47
  • i think you misunderstood my comment above -- it is specifically about your suggestion for a README to "create those CVS reference files", which seems about impossible – cnst Jun 03 '16 at 22:01
  • @cnst I did understood your comment. The README part of my answer stands: you have to explain something. Either my approach (that you won't select), or yours (where you mix metadata and data in the same repo). – VonC Jun 03 '16 at 22:03
  • But your approach doesn't even work, so, why even mention it? And with my approach, why exactly would it have to be explained explicitly in README? An extra README will only add confusion and an extra `diff` compared to upstream, so, why should one even bother with that? – cnst Jun 05 '16 at 20:27