Such IDE integration exists for mercurial, both for Eclipse and Netbeans,
also at shell level.

I really don't get why you say there is no easy way to rollback changes,
because there is. I do manage package updates and installations through
SVN (e.g. updating symfony, doctrine), I just don't use SVN to work with
other people. I believe that managing packages and working with people
should not be regarded as the same thing when talking about versioning
systems.

I think the main and general drive of people for adopting a DVCS is just
that, better workflows, and fortunately, some of them have actually worried
about interoperability, meaning its possible to import files from other
(D)VCSs.

Regards,

David

On Thu, Dec 2, 2010 at 4:02 AM, Lester Caine <les...@lsces.co.uk> wrote:

> dukeofgaming wrote:
>
>> Its actually faster to use the command line when u have enough practice;
>> picture yourself merging branches or something more complicated, I think
>> its easier typing stuff as you think it than finding your way around a
>> GUI, command line reacts faster than a GUI too. I use the IDE
>> integration though, but not the shell integration, at all. I agree on
>> visualizing repository tree on the GUI though. In the end its up to each
>> individual.
>>
>
> This is the key here.
> When working on PHP projects via CVS and SVN I get a view of all the files
> which have changed in the IDE. I can then review those changes and only need
> to select those which do not clash with my own local changes. I can also
> immediately see committed changes that NEED to be rolled back because they
> DO clash with the areas that I am maintaining! Simply automatically merging
> from the command line does not work FOR ME.
>
> DVCS in theory provides a nice way for me to manage my own builds of these
> projects, but the black hole is now how the clash problems are handled as
> there is no easy way to roll back a change that has broken something else.
> Adding the complexity of multiple packages across several projects ...
> smarty, adodb and the like, or building the internal extensions which use
> libraries from the likes of apache, firebird ... in theory should be
> simplified by the use of a DVCS approach, but the reality is that it is
> still very early days and while people are running to a number of camps
> there needs to be a more tidy integration path rather than the current
> diversity that has been created.
>
> I think that what we actually need is a complete rethink of what the
> problems are ... including managing the user projects rather than JUST raw
> source code ... and agree a level of operation rather than the current
> approach of slagging off the paths that you do not agree with. Every package
> has problems and none of them offer a single solution?
>
>
> --
> Lester Caine - G8HFL
> -----------------------------
> Contact - http://lsces.co.uk/wiki/?page=contact
> L.S.Caine Electronic Services - http://lsces.co.uk
> EnquirySolve - http://enquirysolve.com/
> Model Engineers Digital Workshop - http://medw.co.uk//
> Firebird - http://www.firebirdsql.org/index.php
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Reply via email to