Re: Re: CVS Access Method

From: Date: Sun, 04 Feb 2007 16:42:59 +0000
Subject: Re: Re: CVS Access Method
References: 1 2 3 4 5 6 7 8 9 10  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-45580@lists.php.net to get a copy of this message
On 2/4/07, Amir Mohammad Saied <amir@php.net> wrote:
On Sun, 04 Feb 2007 15:07:27 +0100 arnaud@limbourg.com (Arnaud Limbourg) wrote: Bertrand Mansion wrote:
Le 4 f_vr. 07 _ 10:39, Anant Narayanan a _crit :
I also don't find there is enough added value in SVN to switch from CVS. In many cases, SVN is worse than CVS. It won't fit what we need in PEAR IMO. If we were to change, other solutions should also be considered and more modern solutions like a distributed version control system should be tested. I have tested Mercurial and it's great. I think BZR is nice too. I heard that DARCS is excellent. SVN, just like CVS, are things from the past. Did you ever try a distributed version control system before ?
I've used both git and darcs before; and needless to say that the convenience of distributed version control is unbeatable. So yes, I for one, would love it if we actually use one of these modern VCS: Either git, darcs or bzr.
If you know Git and Darcs, you should really give Mercurial a try :)
I've never used any of those in a distributed environment (i use darcs when i need a quickly setup local source control on a box) but they sure look interesting. The fact that we would not really need extra hardware is a plus. Maybe we should give it a try. It will require people to learn a new set of tools so it will take time. Arnaud. In my opinion, the downside of using a distributed environment, is, that we (and our users) will miss the Tooling. As in distributed model there's no more a Server (what we and our users are used to), What would happen to our web-based code browser (currently ViewVC)? I remember, the other day we decided to improve our Bug tracker, and somehow integrate it with our CVS, but we will miss this one too. Most of us are using the *nix machines, without any problems with command-line, but even we have developers who are using Windows which are heavily akin with their used-to-IDE, CVS/SVN integration. IMHO, in a project with this scale (I don't mean the codebase, I mean the number of developers, and the fact that we are scattered around the world [take a look at the map], and we with our unique problems with Internet connections), the old Client/Server model would be much much better.
DVCS are meant to be distributed but you can still have a central system which is meant to be the "server" and you can still integrate things with it. I know that most DVCS have hooks to handle incoming changesets and have online code browsers too, so none of that should be a problem. IDE/Explorer integration can be a problem but SVN has what I'd argue is the best Windows frontend with TortoiseSVN. I'd like to put monotone out there as another option for a DVCS. I've bene using it for more than a year now with OpenEmbedded and am very impressed by it overall. I'm attending the monotone summit this next week so I'll know even more in a week. Of course, this always assumes that we move to a different VCS. It seems there are always some die-hards which think that the past is the end-all be-all and that anything new is a threat to them. -- Justin Patrin

« previous php.pear.dev (#45580) next »