Jeff Rizzo <riz%NetBSD.org@localhost> writes: > I realize not everyone is onboard with the idea of moving towards > using git; however, there's a substantial number of people who would > benefit from having a reliable[1] mirror of the various NetBSD code > bases[2] using git. I concur that reliable mirroring into DVCS is important, regardless of when/if NetBSD and pkgsrc switch. > In order to create repos which maintain longer-term value, I propose > the following: editing the CVS post-commit hook on cvs.netbsd.org to > create a git commit for every CVS commit which comes in for one of the > supported code bases, and commit it to an existing git repo (which > would be created based on joerg's repo-conversion). This would > address several concerns: > > - the repo would always be up-to-date, because every time a CVS > commit happens, a corresponding git commit happens > - the SHA-1 of old commits would never change > - interested parties would gain more experience working with the > NetBSD code using git. This includes, "what do we do in cases where > we would normally use 'cvs admin' to fix the repo?" I have two concerns: It doesn't address the fundamental issue of how allowing cvs admin is inconsistent with a hash-based VCS. There is already a large body of work in conversion tools (e.g. reposurgeon), and it seems like this would be adding a new mechanism which will have to struggle with issues that have already been addressed. > [1] there is a git mirror of src and pkgsrc which is kept reasonably > up-to-date by joerg, but because it is converted anew every time, > whenever someone uses "cvs admin", they potentially change the SHA-1 > of old commits - which makes the git mirror nearly useless (at least > for some uses). So in your proposed scheme, what would happen when someone does cvs admin? The git commit would remain unchanged, so that it would no longer match the cvs history, and would not match (in content; I'm not focused on SHA-1 here) the results of a new conversion. I realize that this may be the best you can do without banning changing history. Another thing is that in the reading I've done about conversions, it seesm like the normal path is to script them and work on the script over time until it's right. That seems different that building up an immutable past history that might later be decided to be wrong. I wonder if reposurgeon has an incremental mode. I will ask esr about that. Two not necessarily related observations: It seems that the git-fast-export format is becoming the interchange language between systems. The issue with converted repo sha changing is a matter of degree, not an absolute issue. If we had an incremental mirror for a year and then an actual conversion, and there was a single sha1 change, then yes it's work for people to replay their changes. Doing this once/year is sort of ok; doing it every week or day is not.
Attachment:
pgp5Uwrx1QybZ.pgp
Description: PGP signature