[fpc-other] [fpc-pascal] Google Code closing down

[Mark Morgan Lloyd]

Florian Klämpfl wrote:
> Am 16.03.2015 um 13:53 schrieb Graeme Geldenhuys:

>> I fully understand that. I think the biggest resistance to migrating to
>> git is the "distributed system" principle. 
> 
> For me
> 1) it is usability, mainly the gui, well, and other stuff like the un-memorizable hashes.
> 2) too much freedom :) svn forces me basically to finish patches: if I started to modify something,
> it is the easiest to finish it than to store it somehow away. git doesn't, just commit when being
> disturbed, add an unfinished in front of the commit message and I can/will continue with something
> else when I come back. For an "idle" time project like FPC this is really a problem for me: my
> git-svn copy contains currently around 60 unfinsished branches :(
> 
> And of course in case of FPC the huge effort to switch the whole infrastructure.
> 
>> That scares people. That is
>> why I introduced the developers, at my previous employment, to git by
>> simplifying things. I let them use a client/server workflow model. That
>> seem to have helped them a lot, and get over that fear they had.

Apologies for resurrecting a fairly old thread, but I've been doing a 
bit of digging for my own interest and want to challenge Graham on one 
or two points.

Before anything else, I think it's reasonable to assume that Git is here 
to stay, in the same way that CVS was here to stay: there might be 
something better in the future, but for now it's something that a 
developer has to know about.

As I understand it, Git is not only distributed but decentralised. That 
is, the cooperating developers maintain an undirected graph of Git 
instances, there is no single master repository: if the project owner's 
servers go down it is not possible to guarantee that the project can be 
reconstructed to an extent that would satisfy e.g. a court investigating 
intellectual property ownership, and that is going to spook corporates 
and their lawyers and should be a concern to free software advocates who 
might need to establish precedence and "prior art".

Now I am sure that Git advocates will point out some bolt-on accessory 
that turns Git into a tree. But when the Git designer (who, I grant, is 
not the current maintainer) is happy to say "You are stupid" to anybody 
who doesn't see things his way, or "You should be in some mental 
institution" to people who find that CVS fits their way of working, one 
has to wonder whether the Git community really would commit themselves 
to that sort of hybrid.

By way of comparison, Subversion has a single, master repository 
generally maintained by the project owner or his agent. If the machine 
crashes he should be able to restore from backups (tape, cloud or 
whatever) and forensic inspection of the failed disc would probably be 
able to confirm that the restored repository was a fair copy of the lost 
one.

The problem with Subversion is that it's entirely centralised. Leaving 
aside Torvalds's arguments about the performance implications ("Merging 
in subversion is a complete disaster [...] and their plan sucks too."), 
I don't think there's an officially-sanctioned way of building a tree 
(or even a star) of caching servers. There used to be something called 
SVK, but even that would only allow a single layer of local caches: 
there was no provision for a group of programmers to have networked 
connection to a departmental server which was a reliable copy of the 
project owner's system.

So it seems to me that one has to concede that Git and Subversion 
between them have pretty much swept everything else off the board, at 
least from the point of view of unpaid developers and free (money and 
beer) projects. Which is unfortunate, since for all its bluster about 
cryptographic consistency checks Git is deficient when it comes to 
guaranteeing that there is a single master copy of a project, and for 
all its accumulated good reputation Subversion is deficient when it 
comes to extending the network architecture and enforcing fine-grained 
security.

-- 
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]