On Sat, Jan 29, 2011 at 4:10 AM, Edward Diener
On 1/28/2011 1:46 PM, John Maddock wrote:
I still haven't heard from the git proponents, what's wrong with using git-svn to manage a local - i.e. distributed - git repository, and then periodically pushing changes to SVN. In other words working with git just as you normally would, except for having to type "git svn" from time to time? This isn't a rhetorical question BTW, I've never used either git or git-svn, so I clearly don't know what I'm missing ;-)
The arguments of Git's superiority as a distributed VCS over SVN's centralized VCS do not convince me either. I understand them but I wonder if the switch from SVN to Git is worth it just so end-users can make their own changes to a local Git repository and then push their entire repository to a centralized location some time later. This is as opposed to SVN users making periodic changes by committing to a centralized SVN repository periodically. I just do not see the big deal in the difference.
I think you're looking at it as a purely tool vs tool comparison which doesn't amount to much. Consider then what the workflow a distributed version control system enables and you might see the difference clearer. Consider a library being worked on by N different people concurrently. Each one can work on exactly the same code locally, making their changes locally. Then say someone pushes their changes to the "canonical" repository. Each person can then pull these changes locally, stabilizing their own local repository, and fixing things until it's stable. You can keep doing this every time without any one of these N people waiting on anybody to "finish". Now then imagine that there's only one person who has push capabilities/rights to that "canonical" repository and that person's called a maintainer. All the N-1 people then ask this maintainer to pull changes in or merge patches submitted by them. If the maintainer is willing and capable, that's fine and dandy changes get merged. Now consider when maintainer is unwilling or incapable, what happens to the changes these N-1 people make? Simple, they publish their repository somewhere accessible and all the N-2 people can congregate around that repository instead. MIA maintainer out of the way, release managers can choose to pull from someone else's published version of the library. Easy as pie. Explain to me now then how you will enable this kind of workflow with a centralized SCM.
I do not see Boost's possible need to become less centralized and go from a monolithic distribution to possible individual distributions as dependent on using a distributed repository model versus a centralized repository model. I believe many other issues are much more important, as brought up by Robert Ramey and others.
How about that try above?
I would much rather Boost have a discussion of those other issues than focus on Git versus SVN, which I think of as just another red herring.
How about the workflow, is that something you'd like to see discussed as well? -- Dean Michael Berris about.me/deanberris