Re: GIT vs Other: Need argument

["Guilhem Bonnefille" <guilhem.bonnefille@gmail.com>]

I'm new to Git, but completly crazy of it.

In my point of view, in corporate team, lot of people does not
want/need the power offered by Git.
So, my conclusion is the better model in a corporate is a centralyzed
repo with some users using Git as "frontend". Other people will simply
use the native tools for accessing the repo.

I didn't try Git with CVS repo but seems less usable in day to day
work than a SVN repo with git-svn FANTASTIC tool.

So the problem is simply now: how to convince people to migrate from
CVS to SVN. This will be really less difficult as CVS and SVN are
quite similar.

On 4/17/07, Tomash Brechko <tomash.brechko@gmail.com> wrote:
> On Tue, Apr 17, 2007 at 10:02:18 +0100, Pietro Mascagni wrote:
> > So, in 15 seconds, how does one argue that GIT is vastly superior to
> > other version control software, especially CVS.
>
> I think you are not talking about choosing SCM for a new project, as
> it is even _hard to imagine_ that one would consider CVS nowadays :).
> And if you are trying to convince people to do the migration from CVS
> to GIT, then technical points alone won't probably help you.  GIT, and
> actually most modern SCMs, are superior to CVS not simply because they
> have some CVS's features improved, and some nice features added.
> Modern SCMs implement completely different workflow model.  GIT's own
> power in its rich toolset, but until people learn (or at least are
> willing to learn) what the workflow is, and how it is supported by
> these tools, there's little advantage in migration.  You can't really
> explain why 'git commit; git push' into some central repository is
> better than 'cvs commit', and pushing after every commit is what
> people will be doing at first ;).  You should also realize that the
> whole process is probably already built around CVS (CVS-specific
> hooks, scripts that access CVS, say, for nightly testing, etc), that
> would also have to be reimplemented.
>
> You may consider another route: create a GIT mirror of CVS repository,
> and update it, say, daily, with git-cvsimport.  Clone from this
> mirror, and work with your own GIT tree, pushing back to CVS with
> git-cvsexportcommit.  Yes, you will be dealing with problems that
> wouldn't be there in the first place if everyone would use GIT, and
> you will basically use CVS workflow, but still, this way is quite
> manageable.  Then approach the most promising guy in the company, and
> explain to him how you benefit from using GIT (gitk/qgit, git-bisect,
> StGIT are among your friends here :)).  As the saying goes, "Better to
> see once, then to hear about a hundred of times".  You are not
> interested in instant migration, and then being blamed if anything
> would go wrong.  When you will grow sufficient number of GIT experts
> in your company, then you will raise the migration question again.
>
>
> Good luck!
>
> --
>    Tomash Brechko
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


-- 
Guilhem BONNEFILLE
-=- #UIN: 15146515 JID: guyou@im.apinc.org MSN: guilhem_bonnefille@hotmail.com
-=- mailto:guilhem.bonnefille@gmail.com
-=- http://nathguil.free.fr/