| 1 |
Stuart Herbert wrote: |
| 2 |
|
| 3 |
>> __Problem: CVS__ |
| 4 |
>> |
| 5 |
>> CVS is one of the worst application ever created. |
| 6 |
> |
| 7 |
> Hear, hear. |
| 8 |
> |
| 9 |
> I'd like to see a move to Subversion made a priority for 2006. If there |
| 10 |
> are problems with Subversion's performance with our tree, engage with |
| 11 |
> its authors to obtain improvements. But get it done. |
| 12 |
|
| 13 |
/me puts on his admin hat |
| 14 |
|
| 15 |
Its going to be a bitch to switch to anything and it would be great to |
| 16 |
have some quantitative (unbiased) proof that such a move will add enough |
| 17 |
benefit for developers and Gentoo to be worth it. Truthfully, I don't |
| 18 |
know much about the other VC's out there (git, subversion, etc). But |
| 19 |
from what I do know, I would say that subversion has the best bet to be |
| 20 |
our preferred replacement. |
| 21 |
|
| 22 |
/me puts on his dev hat |
| 23 |
|
| 24 |
From what I've heard, subversion offers the best features and |
| 25 |
flexibility of the other VC's out there. Granted git has some nice |
| 26 |
features too, but I'd have to evaluate what we really need. |
| 27 |
|
| 28 |
/me puts on his neutral hat |
| 29 |
|
| 30 |
Subversion would be the best bet now because of viewcvs (now viewvc) |
| 31 |
support for it. Changing version control software is going to take a |
| 32 |
*bunch* of work. Things I can think of off the top of my head that will |
| 33 |
need work will be: |
| 34 |
|
| 35 |
* repoman support |
| 36 |
* portage regen tools on the master mirror |
| 37 |
* developer documentation |
| 38 |
* developer training (amazing concept!) |
| 39 |
* massive testing of all issues |
| 40 |
|
| 41 |
Here's an idea I had tonight. Since we're going to be doing the Google |
| 42 |
SoC this summer, perhaps a great project would be having someone work on |
| 43 |
this migration (or at least do an unbiased test implementation). I'd be |
| 44 |
willing to provide an infra server for testing/development. I don't see |
| 45 |
much problem at least trying to work out all the details. I don't think |
| 46 |
infra will go with any change unless there is a clear, detailed |
| 47 |
migration plan with proper back-out plans also. The tree is the most |
| 48 |
important part of our distribution and I'm not going to let such a |
| 49 |
migration go by without proper planning and testing. After the test |
| 50 |
implementation is done and has been fully tested, perhaps the council |
| 51 |
could make the final decision if infra is happy with the |
| 52 |
implementation/migration details. |
| 53 |
|
| 54 |
I'm sure there are going to be unseen issues we won't know about until |
| 55 |
we try a migration. It would be neat if I could provide a developer |
| 56 |
restricted rsync module on the test box so that they can actually try |
| 57 |
using their systems on there. |
| 58 |
|
| 59 |
Anyways, I'd just thought I'd give my input since its going to need to |
| 60 |
go through us eventually :). If people like the idea of having a SoC |
| 61 |
project for this, let me know and I'll have user-rel add that to the list. |
| 62 |
|
| 63 |
Cheers- |
| 64 |
|
| 65 |
-- |
| 66 |
Lance Albertson <ramereth@g.o> |
| 67 |
Gentoo Infrastructure | Operations Manager |
| 68 |
|
| 69 |
--- |
| 70 |
GPG Public Key: <http://www.ramereth.net/lance.asc> |
| 71 |
Key fingerprint: 0423 92F3 544A 1282 5AB1 4D07 416F A15D 27F4 B742 |
| 72 |
|
| 73 |
ramereth/irc.freenode.net |
Archives