1 |
On Tue, 2007-04-03 at 19:30 +0200, Marijn Schouten (hkBst) wrote: |
2 |
> I just don't think it is obvious what tests should be performed. Furthermore the difference between |
3 |
> the different systems is not just performance, but also features. So we need to discuss what |
4 |
> standards any candidate SCM should measure up to. |
5 |
|
6 |
No, we really don't. |
7 |
|
8 |
First off, let's look at things we know we need. This is pretty much |
9 |
the CVS feature set. Next, look at things we want. Does any SCM |
10 |
provide things we want? Now, I'm not going to reiterate all the junk |
11 |
people have said they want, since it's all archived for prosperity. |
12 |
Next, start comparing the things we *require* and the things we *want* |
13 |
in each SCM. Some good metrics people have already been using are |
14 |
server-side disk space, client-side disk space, bandwidth, time for |
15 |
checkout, time for commit, time for update... |
16 |
|
17 |
Also, remember that the needs of the few definitely doesn't outweigh the |
18 |
needs of the many. If 99.9% of the developer pool are doing only |
19 |
checkout/update/commit cycles, then having a 50% drop in performance or |
20 |
a 700% increase in disk usage only to gain features that don't affect |
21 |
the 99.9% make a migration no longer worth it. This is what I mean by |
22 |
using numbers to back up your ideas. |
23 |
|
24 |
> I thought the shortcomings in features of CVS in comparison with SVN were understood. Given in turn |
25 |
> SVN's shortcomings in comparison to distributed SCMs and the abundance and maturity of them it seems |
26 |
> to me that the only decision to be made is what to switch to. |
27 |
|
28 |
What shortcomings, exactly? This is something that you have to |
29 |
quantify. |
30 |
|
31 |
CVS does $x |
32 |
CVS does not do $y |
33 |
|
34 |
I simply have not seen much of anything that would be useful to a large |
35 |
enough section of our developer pool to be worth the problems of a |
36 |
migration. About the only thing I see is "svn cp" to preserve history. |
37 |
I see lots of reasons for it in non-tree repositories, but little in the |
38 |
tree, which already has branches and tags disabled, among other things. |
39 |
|
40 |
> > I don't get why you discuss a distributed SCM, then proceed to talk |
41 |
> > about minimal CD + releases stuff which has nothing to do with the main |
42 |
> > tree. |
43 |
> |
44 |
> Just an example to demonstrate how non-distributed SCM impose artificial restrictions. You wanted to |
45 |
> be convinced, right? I realize the specifics of the example, specifically the expected small extent |
46 |
> of divergence, make this a bad example in practice. But think about the theory. |
47 |
|
48 |
OK. You weren't able to successfully demonstrate anything to me, then. |
49 |
I saw nothing in your mail that showed me why what you described would |
50 |
be a problem, especially considering the examples you used. |
51 |
|
52 |
> But let me try again. Suppose you are developing an ebuild or are cooperating in developing an |
53 |
> ebuild or set of ebuilds with eclasses such as happens now in overlays. Such overlays could just be |
54 |
> branches in the same repository with easy merging between branches which preserves history. All with |
55 |
> one tool. |
56 |
|
57 |
I guess I've just never had the need to do anything of the sort. I'm |
58 |
perfectly capable of using revision bumps and other methodologies |
59 |
already in use in the main tree in my overlays. Why do we need two sets |
60 |
of practices? Why do we need to modify the main tree to fit the model |
61 |
of the much smaller and less utilized overlays? |
62 |
|
63 |
> It would also empower people who don't have push access to the tree or to a specific overlay or to |
64 |
> any overlay, by making it possible for them to do everything people with push access do except |
65 |
> pushing, instead of also making it very hard to use the same SCM. |
66 |
|
67 |
Like what? |
68 |
|
69 |
Qualify your statements. I don't use other SCM software, like many of |
70 |
our developers/users. If you're going to try to tell me that I can't do |
71 |
something I don't want to do, or don't even know is possible, you won't |
72 |
convince me without compelling examples. |
73 |
|
74 |
My point is that instead of discussing all of this yet again, you get |
75 |
together some features you think are required and why, as well as some |
76 |
performance metrics, as I stated above, and try approaching this from a |
77 |
more technical front and less of an emotional one. Like I said, I don't |
78 |
care which SCM you like. You shouldn't care which one I like. There's |
79 |
no way we could ever please everyone, so why even bother to switch? |
80 |
|
81 |
> - From some discussion on irc I learned that lack of tree and history slicing are two concerns of |
82 |
> git's readyness. I hope to do some tests on the tree slicing soon. |
83 |
|
84 |
Excellent. |
85 |
|
86 |
This was something that wasn't available before, so if you're wanting to |
87 |
test it with a newer git that does this well, then that is something we |
88 |
can look at as something that has changed. |
89 |
|
90 |
> I also learned that darcs does not support enough architectures, most importantly mips. Therefore |
91 |
> I'd like to know what architectures need to be supported by a candidate SCM. |
92 |
|
93 |
Ideally, all of them. I would consider dropping support for an |
94 |
architecture we support currently a strong reason to never consider that |
95 |
SCM. If I cannot commit from the machine I'm doing a KEYWORD request |
96 |
on, the SCM fails IMO. |
97 |
|
98 |
-- |
99 |
Chris Gianelloni |
100 |
Release Engineering Strategic Lead |
101 |
Alpha/AMD64/x86 Architecture Teams |
102 |
Games Developer/Council Member/Foundation Trustee |
103 |
Gentoo Foundation |