CVS/SVK/etc.

[Chris Shoemaker]

On Mon, Oct 24, 2005 at 03:03:08PM -0400, Dan Widyono wrote:
> 
> Is anyone proposing a specific re-implementation scenario?  I can see a lot
> of theorizing on both sides, but nobody saying "let's try it *this* way, with
> commits looking like *this*, and patches would be submitted like *this*, and
> *this* would be the release trunk/tree/whatever, controlled by *these*
> people, and a fringe developer would do *this* and *this* is what it would
> look like to the "core developers".  Perhaps people are saying that but it
> seems lost in the fog.  

Ok, I'll try to get specific.  But first, let me say that my premise
is that it needs to be easy for fringe developers to share
"in-progress" code.

Scenario A) Fully Distributed Model
  1) New developers start out by pulling some publicly available repo.
  2) New developers work in their own tree, committing to their local
tree as often as possible and pushing those changes to *their* public
repo, and send out periodic mails to -devel "Hey, I'm starting to
implement foo.  Can you check it out and see if I'm on the right
track.  My repo is at blahblah.net/users/newbie."  
  3) Other interrested developers pull newbies changes into their own
repos, on separate branches, of course.   Review code, comment, hack-a-fix.
  4) Other developer mails back.  "Hey, looks nice, but there's a
problem using frob here, look at my fix, pull from
bloops.net/users/mrexperienced."
  5) Mr. ReleaseManager has of course been monitoring mail, sucking up
patches from mail, doing own dev work, etc.  Release time rolls
around, "Ok guys, it's that time of the month. I've pulled Jack's
whoosiz changes, and Bill's new hobnob code, plus some of newbies foo
changes.  I'm releasing this as 2.1.33, available at
gnucash.org/2.1.33."
  6) All devs pull from new release.  Intelligent merging means it
doesn't take two hours of patch tweaking.


Scenario B) Hybrid Model with Distributed SCM
   1) New developers start by asking for a private dev repo on gnucash
server.
   2) Newbie works locally, commits frequently to newbie's own repo on
gnucash server.  Sends out mail to -devel, "Hey, check out my code"
   3) Other devs pull changes from newbies repo on
gnucash server into own repo on gnucash server, on separate branch, of
course.
   4) Other dev mails back, "looks good, check out my fix though"
   5) Newbie pulls from other devs repo into own.
   6) Mr. ReleaseManager selects changes from all repos on
gnucash.org, makes monthly release, makes it available in "master"
repo.
   7) Everbody pulls from master repo.

Scenario C) Centralized Model
   1) New developers start by asking for SCM account, automatically
get own branch.
   2) Newbie works locally, commits to own branch of centralized SCM,
sends mail, "Check out my code on newbie branch"
   3) Other devs checkout newbies branch, make fixes, 
   4) ????  what? Devs send diff to newbie?  Make a new branch for
fix?
   5) Newbie responds to mystery action in 4) :)
   6) Release manager periodically releases "trunk" branch.
   7) Every dev has to rebase current dev work on new release point,
cherry-picking their own changes that were released in the main
trunk. (*)


(*) Here's where versioned-tree snapshot model really sucks.  Doing
this merge between two tree snapshots is much more painful than
between to changeset-leafs, because the changeset graphs have the
whole incremental history of each branch, whereas the snapshots are
just two tree-states.

Scenario D) Concurrent Model
   1) New developers start by downloading tree from publicly available repo.
   2) Newbie works locally, with NO support from SCM.  (No incremental
changes.)
   3) Newbie starts ambitious changes to code, gets stuck.
   4a) Newbie goes to play somewhere else, frustrated; half-finished
code is forever lost.
   4b) Newbie proceed quite diligently down the wrong path, only to
learn effort was wasted when patch can finally be sent to list.
   4c) Newbie develops *beautiful*, *wonderful*, new feature that now
has to be commited in huge chunks with no development history
recorded.
   5) Other devs can never respond to in-progress code, because it's
never shared.
   6) Release manager makes periodic releases from OneTrueTree.
   7) Fringe devs have to sync with new release, which is exactly as painful as in Scenario C, except there's no history of the sync recorded.
   8) Newbie never gets the benefits of SCM, like incremental
versioning of her changes, because she can't have commit access to the
OneTrueTree.  Use of SCM features, like branching, is only for
"approved" developers.



Is that what you had in mind?  Feel free to add your own, or
expand/correct mine.

 
> At times, it seems that everyone is saying the same thing but in different
> ways.  

:) Are you sure?  And at other times? :)


> There are different ways to control who commits to the Released
> versions, packaged versions, etc.  And that discussion, to me, seems
> orthogonal to "which SCwhatever to use", since all modern source control
> systems seem to support various methods of controlling developer permissions,
> trunks, trees, releases, etc.

Good point.  The real issue is the development model.  But certain
tools lend themselves to certain models.  If there was agreement about
the development model, or even my premise that attracting new
developers is important, there'd be more agreement about tools, I
think.

-chris

> 
> Dan W.
> 
> P.S.  I learned scheme to read GnuCash.  I don't like it, but I learned
> it. :)
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel