From: William Hall <will@gnatter.net>
To: David Bainbridge <david.bainbridge@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: SVN migration
Date: Sun, 04 Jul 2010 18:55:38 +0100 [thread overview]
Message-ID: <4C30CB1A.2030407@gnatter.net> (raw)
In-Reply-To: <AANLkTimtGoNQe2-nA_Qn_qsZP2Iley9x6TU3Ht28Eg4t@mail.gmail.com>
Hi David,
Thanks for your thoughts!
I agree with your points. To an extent, management don't really care how
we implement SCM - as long as it's effective and secure they will trust
the "tech-wranglers" to do the right thing and not impede upon the
company's workflow. Fortunately the industry in which I work is VFX, so
"cutting edge" software is at the core of what we do. I am not imposing
Git because of my own personal preference, I honestly believe that SVN
is simply not the right tool for the job - which will increasingly
involve multi-site collaboration that spans departments as well as
timezones. The ability for two disparate teams of developers to
collaborate effectively without polluting the global codebase is essential.
The limitations with SVN are becoming more and more apparent -
especially now that we have now embarked upon a fairly radical shake-up
of our existing software stack.
I have explained all this with senior management, some who have heard of
Git (and its reputation) and they pretty much say "about time too".
The hard part is that we have two tiers of developers - core software
techies (C++, python) and scripters (python, MEL - these are the people
who make VFX movies, for example, happen). The former will have no
problem with Git, the latter probably just don't care - they just want
to check stuff in and out.)
What I need to do is create this hybrid system that enables the
scripters to pretty much carry on as usual, and to provide the necessary
tools to do SCM more effectively - ie without the overhead of a brittle
SVN environment. If all goes well, we'll take the plunge and make the
switch permanent.
Yes, the technical sell for Git is the easy part, the cultural sell will
be harder. It's up to me to make the business case to the bean-counters
and make the technical transition painless. So far, so good.
I've posted this before, the scripts I am using are available at -
http://github.com/innerhippy/svnAndGit
The more eyes on this the better...
Cheers
Will
On 03/07/10 12:37, David Bainbridge wrote:
> Hi William,
>
> I have been following this thread with interest so I thought that I
> would just throw in my thoughts!
>
> While maintaining synchronization with Git is part of what is needed I
> suspect that this will not entirely convince the management of your
> company that Git is the way forward.
>
> They probably see Svn as a safe repository ... The company's assets
> (intellectual property) are on a central server that is backed up, and
> the contents of that repository can be audited and so on. They may be
> thinking about things like SOX compliance too.
>
> So if you want them to accept Git as a replacement for svn then you
> need to understand and address these concerns. This means that you
> will have to have a conversation with them. To a large extent this a
> people thing ... technical solutions won't necessary convince them.
> They are running a company based on the knowledge and information they
> own - and they want to make sure that it doesn't get lost, stolen,
> corrupted, or whatever. And they are accountable to the shareholders
> for this.
>
> Also, you say that they have been using Svn for donkey's years, so
> from a corporate perspective it probably does what they want and need.
> Otherwise THEY would have decided to change it.
>
> I am in a similar situation and while developers clearly want to use
> gIt, the motivation from a corporate perspective is less clear and can
> be perceived as introducing risk. So we are looking at the wya in
> which repositories are set up, the topology of git repository
> networks, use of Gitosis. Gitolite and Gitorious, and so on, to
> provide some security in the corporate environment.
>
> Every company will have a different view of this so there is no
> 'right' answer. A lot depends on the type of product you produce and
> how long it will need to be supported. If you have products that need
> to be supported for 10 years or more then promoting a tool that is 5
> years old may also raise some eyebrows! You need to have the answers
> ready :-)
>
> Get it right and you will be seen as a hero who understands the
> business. Get it wrong and you will consigned to the religious nerd
> category who just wants to promote his favourite tool ... which I
> would hope is not the case :-)
>
> Good luck with this ... you are not alone!
>
> Dave Bainbridge
next prev parent reply other threads:[~2010-07-04 17:56 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-16 23:02 SVN migration William Hall
2010-06-17 0:41 ` Steven Michalske
2010-06-17 10:33 ` William Hall
2010-06-17 16:27 ` William Hall
2010-06-21 21:12 ` Joshua Shrader
2010-06-21 22:26 ` William Hall
2010-06-26 10:33 ` William Hall
2010-07-03 11:37 ` David Bainbridge
2010-07-04 17:55 ` William Hall [this message]
2010-07-04 22:01 ` David Bainbridge
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C30CB1A.2030407@gnatter.net \
--to=will@gnatter.net \
--cc=david.bainbridge@gmail.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).