Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:50516
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <EF.90.17569.9334EEC4@pb1.pair.com>
To: internals@lists.php.net
Date: Thu, 25 Nov 2010 11:06:30 +0000
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.0
MIME-Version: 1.0
References: <AANLkTinnOnk2FuxdriyksW4zGGCmauWP7XLBqkTVLMgU@mail.gmail.com>	<4CEE0ADA.5010705@lsces.co.uk> <AANLkTimkPyL4=uCaf41cX2dgy4f+_EVJd-s7PpPoixG0@mail.gmail.com> <4CEE1327.7050405@lsces.co.uk> <9A.53.20008.2113EEC4@pb1.pair.com> <4CEE36FC.8080707@lsces.co.uk>
In-Reply-To: <4CEE36FC.8080707@lsces.co.uk>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] git anyone?
From: php@nickpope.me.uk (Nick Pope)

On 25/11/10 10:14, Lester Caine wrote:
> Nick Pope wrote:
>> Ultimately I'm a +1 for Git. The proper branching/merging would solve
>> so many issues that have been addressed recently on the mailing list
>> regarding the pollution of trunk with incomplete and broken features, as
>> well as BC breakage by feature removal...
>
> I have been using Eclipse for development for several years, and
> PHPEclipse does everything I need. CVS and SVN simply work ... fully
> integrated ... and BeyondCompare handles all of the 'merge' problems
> that a simple update or manual merge has trouble with. For that reason I
> have never had a problem with 'merging'.

I wasn't really referring to the diff tools like BeyondCompare.  I was 
referring to having a SCM tool that does *proper* branching and merging. 
  Git does, SVN really doesn't.  Git is incredibly flexible when it 
comes to branching.  It is also space efficient which is useful on large 
projects - a branch isn't a complete copy.  Git is faster/distributed - 
doesn't require access to the remote repository to perform a diff/merge 
- useful if you are without network access.  And generally operations 
are quick because they occur on blobs that contain just the changes 
rather than the entire source tree.

> Eclipse works transparently in linux and windows ... it is the reason
> that I started using it in the first place. I do not have to think
> 'linux ... commmand line'/'windows ... need something else'

Fair enough regarding eclipse...  I wasn't slamming it, I just don't use 
it.  And I don't really find that lack of SCM integration in IDE is the 
end of the world.

But if you are using msysgit which uses a bash shell for running command 
line Git...  You don't have to think any different.

> Neither GIT nor HG integration works with Eclipse so I have to drop
> outside Eclipse to handle picking up changes from github, and for HG,
> the graphics tools simply work transparently. BUT in reality the broken
> Eclipse in integration needs to be repaired if these projects are to
> really support a replacement of CVS and SVN.

I really couldn't make sense of this.  Also - did you actually read my 
last reply?  The link I sent you linked to this:

     http://www.eclipse.org/egit/

I've never used it.  I can't vouch for it.  But if that isn't some form 
of integration, I don't know what is.

> I have wasted weeks of possible real coding time trying to get git
> working for *ME* and I'm not going to spend any more until it is
> available as a working plugin for Eclipse. I AM using HG but simply as
> it was the only way to remain in touch with my main commercial
> activities since those developers forced a change to github.

Fair enough.  I just can't really see that there is that much of a 
problem with Git.  It has rough edges on Windows as I've said in my last 
reply.  Again - there is a plugin.

> I would strongly agree with the statement that CVS is ideal for PHP
> since that at least has a working package management system which has
> worked for years. Managing merges is NOT a problem if you are used to
> tools which fix the problem, in much the same way as third party plugins
> already try to do in git and hg! Currently importing a CVS project into
> either git or hg creates an essentially unusable mess since the package
> management is no longer avialable. How do you combine a 200 package CVS
> project which gets mapped to 200 repos to create a single distributable
> project in ANY DVCS system?

Seriously?  CVS is painful.  Back when I first looked into SCM I brushed 
on it and skipped straight to SVN.

"Managing merges is NOT a problem if you are used to tools which fix the 
problem..."

That goes without saying for pretty much any SCM tool.

"...in much the same way as third party plugins already try to do in git 
and hg!"

Third-party plugins?!  That's news to me.  I think you mean use of an 
external program that already handles diffs/merges.  Why reinvent the 
wheel.  And you were going on about "BeyondCompare".  Would that not be 
exactly the same.

"Currently importing a CVS project into either git or hg creates an 
essentially unusable mess..."

In my opinion it was in a mess in the first place...

"...working package management system..."

I presume this is multiple projects in a single repository?  Yes, Git 
doesn't have that.  Again - it just sounds like a mess to me.  I've 
never had to have a "package management system" in a SCM repository 
myself before, so I guess I cannot comment too strongly on this.

However, submodules do work quite nicely.  I won't pretend that they are 
a perfect solution in every case because the are tied by commit.  Anyone 
who doesn't want the cruft can ignore them.  The PHP repository could 
probably do with some level of segmentation anyway - it is one giant 
monolithic beast at the moment.