[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
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 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
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.
 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.
Main Index |
Thread Index |