Re: What a modern collaboration toolkit looks like

[dhruva]

Hello,
 I request you all to consider the deployment scenerio too and please
do not ignore users/dev on M$.
- git needs a bunch of unix tools and the cygwin bash shell. The user
will have to start getting used to the unix way
- git needs perl (on top of shell)
- mercurial just needs python

I personally find tools with large deployment dependancies a real
problem as each component will keep getting fixes/updates.

-dky

On 1/19/08, Jari Aalto <address@hidden> wrote:
> * Sun 2007-12-30 Eric Raymond <address@hidden> gmane.emacs.devel
> * Message-Id: address@hidden
> >
> > This is a typical modern open-source project.  It's not even a
> > particularly large one -- no more than a dozen core devs, 58
> > developers total.  Here are the collaborative tools we use every day:
> >
> > * Source control with Subversion
>
> I saw discussion that a change from CVS to distributed version control
> is under consideration. To shed a little light to the DCVS scene, here
> is one of my presentations:
>
>   http://www.cante.net/~jaalto/doc/version-control-systems.pdf
>
> Follow the small knobs "*" and underlined words to find out more
> information (URL links).
>
> SUMMARY
>
> The git seems to be overall winner. It's a clear choice for big
> projects.
>
> - Git: phase of development is staggering and in few years
>   the UI/OS compatibility issues are past
>   * The branching and merging "in place" (no separate directories)
>     is thing that excells over any other VCS/DCVS. A Brilliant invention
>     and simple to use.
>   * Vibrant community: ask a question and you get instant answers to
>     anything.
>   * The weak point is UI: it is very complicated. Currently
>     requires very steep learning curve even from users that
>     have prior experience (CVS/SVN stc.)
>
> - Bzr seems to take second place. It has a long term progression path
>   and support, very strict code quality and clearly defined
>   development phases.
>   * I estimate that it will improved in two years time to meet
>     needs of almost any user.
>   * Out of the box Central / semi-central / distributed support
>     (much nicer than git's)
>   * The best is UI: it's very smooth, uniform, logical and
>     a CVS/SVN user is immediately at home with it.
>   * Weak point: performance problems with big repositories with
>     lot of old history. These will however be solved soon (1 year;
>     during 2008).
>
> Despite the popularity that Hg has been chosen by "Big projects" like
> OpenJDK etc., I would not incline to recommended it. Reasons: Too slow
> release schedule, small dev team, unclear roadmap. My observation is
> based on:
>
>   * Page 11: "DCVS Release Schedules"
>   * Page 12: "Pace of Development (1)"
>   * Page 13: "Pace of Development (2)"
>
> Jari
>
> NOTES
> --------------
>
> VCS = Version Control System (software)
> git = Git http://git-scm.org
> bzr = Bazaar http://bazaar-vcs.org
> hg  = Mercurial http://www.selenic.com/mercurial/
>
>
>
> _______________________________________________
> Emacs-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/emacs-devel
>

-- 
Sent from Gmail for mobile | mobile.google.com

Contents reflect my personal views only!