Gregory K. Ruiz-Ade wrote:
> * The distributed nature of hg encourages frequent checkins to
> your local repository without impacting users pulling from
> a "central" repo.
>
> * When you're ready to share your changes with others, you can
> either push to a "central" repo or tell teammates to pull
> from yours.
These two points are what the processes of branching (first point) and
merging (Second point) are for.
In fact, svn/cvs type systems allow your personal branch to be easily
fully backed up by the project/corporate backup system. You don't want
your local repo (git/mercurial) to be completely lost when your dev
machine becomes unavailable. (fire/theft/technical mayhem)
I guess the biggest design difference is more like the cathedral vs.
bazaar development styles. Git/Mercurial lend themselves to the bazaar
vary easily. Anyone can fork the repo and start their own development
team (or just themselves) around the new fork. With their own branches
and tags. Then submit "Big Patch" (or tar of repo) back to the main
project if they want. (Since public merging is usually not implemented.)
Currently, the only reason that I (personally) see for a cathedral type
development team to use git/Mercurial type systems is if they have
load(too many ci)/access(network usually inaccessible/slow) issues to
the central repo. Just have to make sure the local repo is backed up.
--
END OF LINE
--MCP
_______________________________________________
Discuss mailing list
Discuss@lopsa.org
http://lopsa.org/cgi-bin/mailman/listinfo/discuss
This list provided by the League of Professional System Administrators
http://lopsa.org/
