On Wed, 2008-04-30 at 03:06 -0700, Jakub Narebski wrote: > Richard Purdie <rpurdie@xxxxxxxxx> writes: > > > I've been wondering about whether its possible to provide some degree of > > traceability of commits to a shared git repository. The potential > > nightmare scenario is one developer making a commit pretending to be > > someone else. > [cut] > > If you really need that, perhaps you would be better with using > Monotone, with its elaborate security and trust-related features? > > IIRC we recommended Monotone to IPSec folks here... The project I'm thinking about is OpenEmbedded which used to use bitkeeper and switched to monotone when bitkeeper went private only. The issues with monotone are ones of poor performance, particularly with the usage patterns we have, lack of good branching/merging capabilities, lack of good web interfaces, high server load, some breakage issues and a now general ill feeling amongst OE's developers. Whilst monotone has improved tremendously from where it was, I'm not sure certain features we need are going to appear in it within the medium term which makes git look attractive. When we switched to monotone we also lost our bitkeeper history which I'd like to see us reunited with. I've been trying to make a sane conversion of the bkcvs dump to git using git-cvsimport and the bkcvs mode of cvsps but I'm having problems which I'll perhaps mention in another email once I've had time to try and understand them properly. Its by no means certain OE will switch but we want to setup a git trial system and see exactly what we gain/lose. Evaluating the 'security' consequences of a move is part of the equation. hg is another option under consideration but not many of us have experience of it and we're wary of choosing an SCM with a smallish userbase again amongst other things. Cheers, Richard -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
