From: Brian Mitchell Date: 2007-03-13T11:51:09+09:00 Subject: Re: Why SVN? On 3/12/07, Jeremy Tregunna wrote: > On 12-Mar-07, at 8:05 PM, James Edward Gray II wrote: > > For example, I really doubt there are many patches to Ruby I want > > to skip out on. > > There may be patches I'd want to skip out on in other projects -- > platforms I don't need support for, objects I won't use, you can > continue this line of thought. Not having the ability to just discard > those w/o affecting the repo's consistency, is nice. Sure it'd only > be used in corner cases, but when you stumble across such a corner > case, you'll wish you had that ability (or maybe you won't, who am I > to say). > I think you hit it in just one direction. The real value I find in cherry picking is when I am providing a set of patches to an upstream developer who may or may not want to merge certain things at any one time. Most distributed systems handle this quite well though I think darcs wins when it comes to the user effort needed. Other systems often rely on complicated patch maintenance systems or force constant "rebasing" patches with each revision (better than no support though). The end result seems to be that you can avoid playing the baby sitter between branches all the time. No more merge chores just to keep things up to date. Of course, that isn't to say that avoiding merge work always works either. With all of this talk about SVN vs. anything not CVS, I would love to see some ideas of how one could apply an svn interface to an existing distributed tool. Some get close but maybe someone should make a centralized "porcelain" for git? I don't see any reason you couldn't implement a good portion of behaviors people seem to like. Brian.