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