On 1/3/14, 3:22 PM, Roy Marples wrote:
Hi Jeff On 03/01/2014 21:57, Jeff Rizzo wrote:We've had a good friendship in the past and I wouldn't want to affect that in anyway, but equally I feel I must say what I believe when in disagreement especially as your tone was "my way or the highway".
Well, my tone was intended to be "I'm doing this" - but as what I'm proposing to do is in no way a final state, I'm not really sure why it matters. Here's something I want to be clear on: I am not proposing to make any changes at this time to the authoritative source of NetBSD - it is now, and will continue to be for some time (including after I have done whatever work I do on the post-commit hook), CVS. If you want to say, "You're wasting your time" - fine, but it's my time to waste. I am working on solving a real problem for real people. If you don't see it as a problem, well, we'll just agree to disagree.
I am proposing to do work to address an issue which is relevant to some (many, in my view) people. I'm sorry if you're not one of those people. Please also see comments inline, below.Oh don't get me wrong, changing from CVS is very relevant to me. I just feel that going to git directly is the wrong approach.By moving to fossil as the main repository it allows several things1. We can ship fossil in the base system quite easily - this is just not practical with git as functionality dependant on python or perl would not work.2. It's possible to have a bi directional fossil <-> git bridgeWhile 2. would equally work with git as the "main" repository I strongly feel that NetBSD should be self updating from the base system. Also, you then get to work with the SCM of your choice. I choose fossil, you choose git. I'm also sure that there could be caveats to this approach, but equally I think it warrants investigation.
Well, here's the thing: it's been under investigation. And it will likely continue to be. However, there has been no real movement on the fossil end of things (at least that I've seen, for NetBSD-moves-to-fossil) for years. Last I knew, and as far as I know what continues to be the case, is that fossil's network code is very slow for large repos and would likely not work in practice for us as-is. This is where things have been left for over two years - if they're likely to change, that's great, but I am not willing to fight that fight without more evidence that fossil itself wouldn't be part of the problem.
We've been stuck in more or less the same place, repo-wise, for years. This is what *I'm* doing to move us forward. The state of the world in 2014 is that interoperating with git is important, in order to be taken seriously. Interoperating with fossil, while I agree it would be cool and in some ways better, is just not that important. I'm certainly not stopping anyone from completing that implementation...
+j