On Monday 12 March 2007 10:51 pm, Brian Mitchell wrote:
> 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.

I'm just catching up on some old email (so my comment may be far off the mark 
(or out of date)), but you (anybody ;-) might want to look into svk (try 
googling for it).  

I haven't tried it, but it was recommended to me as sort of a front end that 
would let me:
   * use svn type commands
   * maintain a local and remote repository (i.e., distributed)
   * and the remote repository could be a variety of things, including CVS, 
SVN, Darcs, and ...?

Randy Kramer