tech-repository archive

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

Re: Proposal for more reliable git mirroring

On 1/3/14, 12:50 PM, Roy Marples wrote:
On 03/01/2014 19:24, Jeff Rizzo wrote:
I realize not everyone is onboard with the idea of moving towards
using git

This is true, I for one, would rather move towards more suited to our workflow and ideals, namely fossil.

I understand the thinking behind this, but from my perspective one left-behind software project is enough for me. (Talking about NetBSD, here) I've worked with most of the other DVCS solutions at least a little bit, and it is so clear to me that git has won the mindshare that I'm not willing to fight an uphill battle for another solution, given that source code management is not the end goal for me. If someone wants to create a working solution using fossil, that's great, but it's not where I'm going to spend my time.

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

What happens if the git repo goes offline? Would it reject the cvs commit (bad), lose the git commit (worse, rebase required again?) or store it locally until it comes back up?

I haven't actually written anything at this point, but the idea would be that an exceptional situation would require manual intervention, at least during the development phase, and I would anticipate maintaining enough state to be able to replay any commits into the git repo.

The "official" repo will be on the same hardware (unless, as I mentioned, there becomes a resource contention issue), so there should not be the case of the git repo being "offline" in that sense.

 - 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 fail to see how this improves the current situation we have on github.

The situation we have with github is that the repo changes in a way that people trying to pull updates get screwed. One of the goals of this endeavor is to keep that from ever happening.

[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).

From memory, Joerg maintains the git repo from the fossil one which doesn't suffer from this (Joerg, please correct me if I'm wrong).
If so, why place this extra burden on a git deficiency?

Because I, and many others, are interested in working with the NetBSD source using git. I will admit to not having used fossil in anger much, but the few times i played with the NetBSD repo using fossil, it was too slow for network updates, and frankly, given the fact that almost everything else in the known universe is using git these days, i just don't have the patience.


Home | Main Index | Thread Index | Old Index