Re: Mercurial - Distributed SCM in Gnome (Was: Git vs SVN (was: Can we improve things?))

["Kalle Vahlman" <kalle vahlman gmail com>]

2007/9/23, Ali Sabil <ali sabil gmail com>:
> On 9/23/07, Kalle Vahlman <kalle vahlman gmail com> wrote:
> > 2007/9/23, Ali Sabil <ali sabil gmail com>:
> > > I think as well that mercurial is very easy to use compared to git,
> >
> > I don't get this argument, looking at
> >
> >   http://www.selenic.com/mercurial/wiki/index.cgi/QuickStart
> >
> > tells me that the basic commands one would use for daily development
> > are almost exactly the same as in git. Am I missing something?
> >
> I am not talking about the command set, I am saying basically, that to
> use git you need to understand its inner working otherwise you are
> pretty much lost, that's definitely not the case of Mercurial nor bzr.

Sorry, but I did get lost while trying Mercurial just now. I can't
understand why I need to merge something that I just committed. I
mean, I just modified a file, committed the change and then tried to
push the committed change to the place I cloned from. The result was a
complaint that it would create remote branches and I needed to merge.
Merge what to where?

Please don't try to tell me that it should be obvious "without
undestanding its inner working" since it's not. You need to learn what
it does when you commit (and that is fine with me), please don't
pretend you do not. The situation is hardly different with git.

> > > but am not sure about the merge capabilities of Mercurial. I think
> > > that git complexity comes from the extension mechanism used by git :
> > > none.
> > >
> > > Basically git is extended by writing shell scripts and perl scripts
> > > that create new commands
> >
> > Isn't this conflicting a bit with what you just said? Furthermore, you
> > can write your tools with whatever you want; Python, Perl, Ruby etc.
> > With Mericurial extensions you are limited to Python. So you could say
> > that the extension mechanism of git allows more options than
> > Mericurial...
> >
> I don't know if you are serious, but do you really think that Git is
> extensible ? I would rather say it got a pseudo extension mechanism :
> scripts that operate on the repository.

I guess we have different meaning for the word then. What do your
extensions do, if not operate on the repository? I thought the whole
point of extensions is to import, modify or export data to, in and
from the repository.

> And btw, it is technically possible to extend bzr and Mercurial using
> external tools written in other languages that operate on the
> repository in the same manner as Git. But I would stay away from that
> : it is just plain ugly.

The reason why it's NOT ugly with git is that git commands are
designed to be used that way, while Mercurial and others are not.

> > > for example git-svn looks like a completely
> > > separate tool, where as bzr-svn for example just integrates into bzr,
> > > and any bzr command works on the svn repo as if it was a bzr repo or a
> > > bzr branch.
> >
> > I don't see the big issue with this. git-svn is also only the glue
> > from svn to git, all other work is done on the git repository as
> > usual.
> >
> git-svn dcommit ? anyone ? In fact git-svn as a program should not
> exist in the first place if git had a serious extension mechanism.

Now I'm really lost, so do you mean that git should talk directly to
the svn server when committing or..? Because that would naturally
negate any benefit from a local repo...

How does bzr handle that?

> Please consider trying both bzr (>= 0.91) and mercurial, and judge by yourself.

I tried Mercurial and the result was given above. Maybe I'll try bzr later too.

-- 
Kalle Vahlman, zuh iki fi
Powered by http://movial.fi
Interesting stuff at http://syslog.movial.fi