-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chris Gianelloni wrote: > On Sat, 2007-03-31 at 11:52 +0200, Marijn Schouten (hkBst) wrote: >> So in light of all that I don't think it is wasteful to restart this >> discussion. > > I do. > > Want to bring it back up? Go perform some tests and report back with > some data if you feel prior efforts weren't done properly or > reproducible. My *entire* point was that *discussion* of this issue is > worthless compared to numbers and data. I see no need to hear 300+ > people tell everyone else their *opinion* on what they *think* is > better. Seeing some actual data, though, should be definitely > encouraged. > Again, if you want to see the tree converted to something else, you need > to show compelling reasons and data *why* it should be done. Discussing > it doesn't really show those things and lends itself to giving only > beliefs, political or personal, about given SCM software. I honestly > don't care what anybody *thinks* about any particular SCM. I am > interested in the facts and numbers. I don't have much preference > myself other than that I already know CVS/SVN. If we were to make a > change, even to SVN, I'd like to see some well-thought-out reasons why > and some numbers to back it up.
I just don't think it is obvious what tests should be performed. Furthermore the difference between the different systems is not just performance, but also features. So we need to discuss what standards any candidate SCM should measure up to. I thought the shortcomings in features of CVS in comparison with SVN were understood. Given in turn SVN's shortcomings in comparison to distributed SCMs and the abundance and maturity of them it seems to me that the only decision to be made is what to switch to. > I don't get why you discuss a distributed SCM, then proceed to talk > about minimal CD + releases stuff which has nothing to do with the main > tree. Just an example to demonstrate how non-distributed SCM impose artificial restrictions. You wanted to be convinced, right? I realize the specifics of the example, specifically the expected small extent of divergence, make this a bad example in practice. But think about the theory. But let me try again. Suppose you are developing an ebuild or are cooperating in developing an ebuild or set of ebuilds with eclasses such as happens now in overlays. Such overlays could just be branches in the same repository with easy merging between branches which preserves history. All with one tool. It would also empower people who don't have push access to the tree or to a specific overlay or to any overlay, by making it possible for them to do everything people with push access do except pushing, instead of also making it very hard to use the same SCM. - From some discussion on irc I learned that lack of tree and history slicing are two concerns of git's readyness. I hope to do some tests on the tree slicing soon. I also learned that darcs does not support enough architectures, most importantly mips. Therefore I'd like to know what architectures need to be supported by a candidate SCM. Marijn -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGEo81p/VmCx0OL2wRApQxAKCh+ZB64BnDId+ZLPDh2k3xxIoQFgCgsLTJ pFc/u9hEFshBUAIhXlvGgLk= =j+xm -----END PGP SIGNATURE----- -- [email protected] mailing list
