Thank you very, very much Konstantin for the detailed reply... you answered
all of my questions and also included lots of great supplemental
information.
I concur with your comments about the "marketing speak" and the "cloud,"
and I apologize for not phrasing my questions in a more clear and concise
way.
WRT 1.a: Voluntary pushes by devs to synchronize repos based upon agreed
policy is the model I was attempting to describe (obviously poorly, sorry).
WRT 1.b: I am surprised by your comment that private Git repos purchased
from Github are not secure... they purport to be authenticated and use SSL
connections. Other than the employees at Github, who's prying eyes would
be able to peruse the code?
WRT 3.c: By "secure" I meant a user/password protected, SSL connection to
a web-based UI over a private and (hopefully :-) secure Git repo hosted by
a Git hosting provider.
So, based upon your thorough reply, it appears that Git will do everything
we need it to do (and more). And we will review the options for off-site
"secure" repository backup to determine where the best cost/benefit will be
for our organization.
Thank you again for your counsel,
Greg
On Wednesday, January 9, 2013 9:09:28 AM UTC-8, Konstantin Khomoutov wrote:
> On Tue, 8 Jan 2013 15:51:18 -0800 (PST)
> Greg <i.a...@comcast.net <javascript:>> wrote:
>
> [...]
> > 1. A general architecture as follows:
> > a. Distributed repository model where local "branches" are
> > permitted and all repositories are kept in sync with "reasonable"
> > latency (I believe Git does this; please correct me if I'm wrong)
>
> This sounds like some kind of marketing speak so it's not quite clear
> what's being asked here. If you ask about some sort of *automated*
> synchronizing of developers' repos to a central ("master", "blessed",
> "reference" or whatever else you'd like to call it) repo then no, Git
> can't do it by itself. If what's hidden behind this phrase is whether
> developers are able to periodically push their work somewhere then
> the answer is yes (obviously). But such pushes are only done
> voluntarily unless you deploy some sort of crazy scheme which would use
> a scheduler and some custom code to automate such a task. In general,
> when working with Git, a policy regarding code organisation and
> workflow is developed and agreed upon, then everyone follows it.
>
> > b. Capable of synchronization with a secure repository in the
> > cloud as redundant off-site storage (either free or subscription)
>
> Another case of marketing speak: the word "cloud" is so tired everyone
> has its own set of meanings for it. To provide an off-site emergency
> storage for your Git repo(s), you have several possibilities:
> * Buy private hosting from a Git hosting provider (such as bitbucket,
> github etc) -- this is really a no-brainer setup.
> * Buy a VPS or a dedicated server (running a Linux-based OS) and host
> your backup repos on it -- this is slighty harder to set up, but
> only slightly.
> These two possibilities suffer from the same syndrome: they won't
> protect your code from a prying eye and are unable to keep your trade
> secret, if any, so there's another one:
> * Buy/rent some storage (be it a server or a dropbox-like service)
> and periodically upload there encrypted backups of your repos
> made by the `git bundle` tool (which is an integral part of Git).
> This is not bandwidth-effective but should in exchange be reasonably
> safe security-wise.
>
> > 2. Provide a seamless developer SCM experience from within the
> > following development environments:
> > a. Microsoft Visual Studio (HTML/JavaScript/C# development for
> > PC/Windows and Windows Phone)
>
> No native (i.e. "made by Microsoft") tool, but Git Extensions [1] claims
> to have support for the whole range of contemporary MS IDEs.
> I have only used Git Extensions in the standalone mode, and it rocks.
>
> > b. Eclipse (HTML/JavaScript/Java development for Android devices)
>
> Yes, via its EGIT plugin [2]. I, again, have no personal experience
> with it, but it's reported to work OK.
>
> > c. Apple Xcode (HTML/JavaScript/Objective-C development for
> > Mac/OS X, iPad, iPod, and iPhone)
>
> XCode has built-in support for Git -- at least version 4.2 running on
> Mac OS X 10.6.8 (I've had a chance to tinker with it just today).
>
> > 3. Provide full-featured user interfaces for the following
> > platforms (particularly where IDE integration in #2 above is not
> > available):
>
> Not sure what does "full-featured" really means here.
>
> On all platforms Git is ported to (namely, everything POSIX, including
> Mac OS X, and Windows), it comes with its full set of command-line
> utilities and its two standard GUI tools (`git gui` for arranging
> commits and working with remote repos and `gitk` which is a graphical
> history browser). Git's command line tools are able to work with a
> wide set of diffing GUI software (such as vimdiff, meld, KDiff etc) and
> could be set up for custom front-ends as well.
>
> > a. PC with Microsoft Windows 7 (GUI and command shell,
> > preferably PowerShell)
>
> Works OK in cmd.exe. Works almost OK in the port of the GNU bash shell
> (which is packaged with Git for Windows) -- no support for non-ASCII
> characters. Don't know for PowerShell but heard it works there OK as
> well.
> Several technical issues exist:
> * There's no 64-bit binaries of Git for Windows so you won't be able
> to handle files larger than some 2GiB.
> * Pathnames longer than 260 or so characters are not supported
> (i.e. Git does not internally uses those hacks with "\\.\" pathname
> prefixes and relies on "more standard" APIs).
> * Certain obscure bugs persist (though you're unlikely to encounter
> them).
>
> > b. Mac with OS X (GUI and command shell, if available)
>
> It's just a POSIX system, so nothing special about it.
> There were certain issues with funky approach to handling Unicode in
> HFS but they've been fixed in 1.8 or even earlier.
>
> > c. Browser-based web interface for the secure repository in the
> > cloud (for use on machines/devices where Git is not installed)
>
> I hear this stupid word again...
>
> There are three sorts of web front-ends to browse Git's history:
> * Proprietary web front-ends provided by the Git hosting providers.
> * A de-facto standard free tool called gitweb -- it usually comes
> packaged with any sensible OS which has Git packaged, so if you're
> about to deploy/rent a server, you can install gitweb there.
> * There are certain free "turn-key" solutions to host Git repos such as
> GitLab [3] and Gitblit [4] -- they provide their own means to browse
> the repos they host, just like front-ends of proprietary services.
>
> Hence I'm not sure which from what I referred to applies
> to "the cloud" -- take your pick. It's also not immediately obvious
> what does "secure" means here -- should the access to that web
> interface be restricted in some way (like being protected by a
> password)?
>
> 1. http://code.google.com/p/gitextensions/
> 2. http://www.eclipse.org/egit/
> 3. http://gitlabhq.com/
> 4. http://gitblit.com/
>
--
