On Sun, Aug 05, 2012 at 05:35:47PM -0400, Kenneth R Westerback wrote: > On Sun, Aug 05, 2012 at 03:00:04PM -0400, Ted Unangst wrote: > > On Sun, Aug 05, 2012 at 10:46, Darrin Chandler wrote: > > > On Sat, Aug 04, 2012 at 07:05:38PM +0200, Marc Espie wrote: > > >> Well, git just has a different set of bugs than cvs. > > > ... > > >> I would deem cvs MORE painful than git on average, it's just that > > >> we're more accustomed to the pain... > > > > > > Yes, this is right. And also there would be a price to pay in lost > > > productivity in switching to a new system. To those very familiar with > > > CVS and not very familiar with Git (or hg, et al), the benefits of > > > switching are nebulous and uncertain, while the cost is very real. > > > > I will add a somewhat controversial viewpoint to the mix. Because cvs > > makes working with branches and large diffs so painful, it forces > > developers to split their work into smaller pieces. In OpenBSD, > > that's a good thing. Keeping your changes in a private fork is > > difficult, which is good. It means fewer private forks. If every > > developer could maintain a branch with some private tweaks, and not > > bother integrating their changes or fixing regressions, progress would > > grind to a halt. [I have mentioned this to people before and their > > eyes just about popped out of their head. I don't expect > > everyone to agree.] > > ++1 here. My only experience with a project that moved from cvs to > git was that a) the number of brances exploded and b) the number > of repositories containing branches exploded and were erratically > interconnected. > > This resulted in many rotting branches, many private playgrounds > and far less incentive to move forward together. I particularly > enjoyed messages containing lists of random hex numbers that one > should revert, merge with or sacrifice chickens over if one could > only find the appropriate repository. >
I can share that we had the same experience when we started to use git at work: exploded and rotting branches, playgrounds, and all these troubles with git-isms and endless ways to do the same thing. But, quite frankly, it is a sign that a) the release maintenance sucks. b) the willingness and experience to master git is missing. After more than two years, we got used to git, established stricter rules, and I think we got rid of these problems plus having some of the benefits and reliefs over CVS (see espie's mail for a few examples). Most importantly, unused branches have to be deleted from the server, people have to work and develop in "master", and arbitrary experiments do not belong on the shared remote, unless they are important or intereting for others. If people do not test their changes in master, they will keep on breaking the tree and you'll have to deal with them personally (I think that is the "social" part of the model). After all, git is not github. The latter is the same old bazaar-like model where everyone does something somewhere and it eventually turns into releases, excluding quality. You do not have to use git like that, but it is a learning curve for people who only knew github. You can use git in a more traditional, centralized and self-hosted way. > OK, one experience but it left an indelible impression. :-) > > I think git gives you a lot of rope. It does. I'm fine with using CVS in OpenBSD. Reyk
