On Tue, 8 Jan 2013 15:51:18 -0800 (PST)
Greg <i.am...@comcast.net> wrote:
> 1. A general architecture as follows:
> a. Distributed repository model where local "branches" are
> pemitted 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
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
> 2. Provide a seamless developer SCM experience from within the
> following development environments:
> PC/Windows and Windows Phone)
No native (i.e. "made by Microsoft") tool, but Git Extensions  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.
Yes, via its EGIT plugin . I, again, have no personal experience
with it, but it's reported to work OK.
> 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 #1 above is not
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,
> preferrably 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
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
> b. Mac with OS X
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  and Gitblit  -- 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