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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
