tech-repository archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Proposal for more reliable git mirroring

Jeff Rizzo <> 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 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

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

Home | Main Index | Thread Index | Old Index