Re: [xmlvm-users] Adding new committers

[Joshua M. <xm...@me...>]

Hi all,

I was recently part of a SCM discussion.  In comparing distributed vs
traditional source control we have basically come down to understanding that
you can do exactly the same things with each.  The only difference is
whether their command line clients make it easy or not.  Distributed SCMs
seem to focus on making merges easier, traditional focus on carefully
tracking what goes in to branches.  Distributed seem to spend more time on
their merge tools, so they seem to merge better..

Regards,

-- Joshua Melcon


On Mon, Jan 10, 2011 at 3:08 PM, Panayotis Katsaloulis <
pan...@pa...> wrote:

>
> On Jan 11, 2011, at 12:48 AM, Paul Poley wrote:
>
> > You can do the same thing with subversion.  It's quite easy to make
> branches & merge with it as well.  I'm not familiar with Mercurial/GIT, but
> I'm assuming it's just a matter of who's familiar with what.  I'm not
> directing this at you.  Rather, you could say this about me & Mercurial/GIT,
> but to steal a rather famous quote:
> > "You always fear what you don't understand"
> >
> > Yes, you can do automatic merging with subversion too, but that misses
> the point.  Each merge described is a purposeful human decision or we would
> forget about the branches.  If we think that's too much trouble or too
> complicated, we don't have to do branching or tagging, but I'm trying to
> keep quality code separated.  Just because someone wrote some code doesn't
> mean it's worthy of trunk (myself included).
> >
> > So to reiterate, my thoughts are just discussion.  Please feel free to
> give input or critique.  If you have ideas/comments on Mercurial/GIT, please
> do share.
>
>
> I am just talking after my own experiences.
> I've used SVN for a long time and I was too reluctant to move on to
> mercurial. But there were real advantages on using mercurial instead of SVN.
>
> What SVN actually does with branches is to copy the whole directory
> structure over and over again. To drop a branch or merge two branches was
> (in my experience) a nightmare, especially if 3-way merge was required (i.e.
> changes were performed on the same block of code). Moreover, other resources
> like binaries or files moving around were implemented by a non-optimized
> way; not to mention the time and internet requirements in the case someone
> wants to go from one version to another. Even worse, moving from one branch
> to another was practically moving from one project to another with nothing
> in common.
> All these problems made the whole procedure slow, bulky and not really user
> friendly.
>
> Distributed versioning systems have proved to solve these problems in an
> elegant manner. I've chosen mercurial, but this doesn't matter - any one is
> good.
> I can only say that when I went to mercurial, I couldn't go back. I've
> actually used a lot mercurial during the last months with XMLVM. I've
> created monster patches, when at the same time official XMLVM tree moved
> along, and resolved all merges with success. I am convinced that, without
> the help of mercurial this continuous merging and developing would not have
> been possible.
>
> ------------------------------------------------------------------------------
> Gaining the trust of online customers is vital for the success of any
> company
> that requires sensitive data to be transmitted over the Web.   Learn how to
> best implement a security strategy that keeps consumers' information secure
> and instills the confidence they need to proceed with transactions.
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>