Re: [tlug] bash and grep and diff

["Stephen J. Turnbull" <stephen@example.com>]

Fredric Fredricson writes:
 >   On 08/14/2010 09:35 AM, Stephen J. Turnbull wrote:
 > > Fredric Fredricson writes:
 > >
 > >   >  I guess the strength of git is the same as it's weakness, no
 > >   >  central repository.  /Fredric
 > >
 > > Why is a lack of a central repository a weakness?

 > Not a weakness for an open source project, but for commercial it
 > might be.

I still don't see why *no central repository* is a problem.

 > There should never be a question on where the "original" is and all
 > changes need to be tracked,

*snort* Do you really think anybody doesn't know which is the
"original" Linux?  C'mon.  And all changes are tracked; they're just
not necessarily all on the same storage volume.  If you want to ensure
that all changes are available to the company, you just do the same
kind of thing that has always been done: workers use company
controlled SANs, not local hard drives, for storage, only
company-owned hardware is allowed to connect to the net, and maybe
even no hardware that can connect to the repo is allowed to leave the
premises.

 > even those made to development branches that does not go into the
 > main codeline (each change is made for a reason and that should be
 > documented, checking in a bulk of changes and just calling it "new
 > function X" is not really professional).

That's a management function.  Surely you're not claiming that
Perforce is capable of reviewing log messages and ensuring that they
are accurately describing the diff?

 > I have used Perforce a lot and most of the things LT claims to be
 > next to impossible with all systems but git like creating and
 > merging branches, "diamond"-style merging (make two branches, make
 > changes, and merge these two branches to a third branch, that later
 > will bet merged with main) is easy and fast (perforce helps you a
 > lot).

Could be.[1]  But I don't see what that has to do with commercial
development needing a centralized repository.

It seems to me that commercial development requires identifying the
official versions, but that can be determined by who signed the commit
rather than where the repository is located.  Commercial development
requires strong auditing features so you can track claims that code
not owned by you is propagating through your system.  Bitkeeper has
such features, and to some extent I expect they could be built on the
"pickaxe" feature of git.  I suspect that what really is going on,
though, is that owners of commercial code fear that it's too easy for
their proprietary stuff to leak out if their developers are using
DVCSes.




Footnotes: 
[1]  Of course, there are a lot of refugees from Perforce-land on the
various DVCS user lists who say it was a pretty horrible experience.
Maybe you were just as lucky with Perforce as I've been with CVS? :-)