Re: [tlug] bash and grep and diff

[Fredric Fredricson <Fredric.Fredricson@example.com>]

 On 08/15/2010 02:57 PM, Stephen J. Turnbull wrote:
> 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.
As far as I know there are several "original", even if Linus, sort
of, control the "real original". I guess that RedHat have their own,
for example. But that is totally beside the point, since I do not
advocate a central repository for open source projects.
> And all changes are tracked; they're just
> not necessarily all on the same storage volume.
So where exactly are they? It works fine for open source not
to know, perhaps, but not for commercial developers that have
to fix bugs in software written three years ago.
>   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.
I want all changes in one place, not scattered over a lot of drives,
company controlled or not. Managers and other programmers should
not have any problem finding the changes and descriptions.
>   >  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?
No a central repository can not guarantee that, but it makes it
possible and quite easy to get.
Still, you have to hire professionals that know that 80% of the
development cost (or so) is maintenance so they are smart enough
to leave tracks.
>   >  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.
I just point out that it does not take a distributed repository (or
git) to make merging easy. I definitely got the impression that LT
claimed this.
> 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.
And that person would be who? Staff change. That is however not
the main reason for a central repository, it's the history.
>    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.
No, not really. What commercial developers fear the most (those
in the know) is that the code base become unmaintainable.
Source code embed knowledge and contrary to what some young
programmers I have met believe it is usually not commercially
feasible to just throw it away and start anew (until the dreaded
day when it, for one reason or the other become necessary (usually
because of new technology or hardware limitations)).
> 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? :-)
You should not rely on luck. That's why Perforce have atomic submits
of a set of files with transaction control. That alone make Perforce
totally superior to cvs. I believe svn (and git) have similar features.

/Fredric

begin:vcard
fn:Fredric Fredricson
n:Fredricson;Fredric
org:Ln4 Solutions AB
email;internet:Fredric.Fredricson@example.com
title:CTO
tel;home:+46 8 91 64 39
tel;cell:+46 70 677 58 48
version:2.1
end:vcard