Source control for all dmd source (Git propaganda =)

[Leandro Lucarella]

"Jérôme M. Berger", el  3 de junio a las 23:09 me escribiste:
> Leandro Lucarella wrote:
> >"Jérôme M. Berger", el  2 de junio a las 21:29 me escribiste:
> >>	I've started. I'll give you a full report tomorrow when I have
> >>	tested it more completely, but I have to tell you that it doesn't
> >>	look good for Git. Now, I have to ask: have *you* tried Mercurial
> >>	or Bazaar? And what, in your opinion, is the main advantage of Git
> >>	over the other two?
> >I've tried Mercurial. I'm using it now because some Pythons projects I'm
> >working with (and LDC) use it. I think I tried Bazaar a long time ago, and
> >it was awful in terms of usability (or maybe it was GNU arch?), but
> >I definitely can't speak about Bazaar.
> >Why I think Git is better? Mainly because of how flexible it is in terms
> >of repository manipulations (aka git rebase -i [*] =),
> 
> 	First I should say that I consider rebase to be a complete
> 	misfeature of any version control system. One of the main points
> 	of version control is that you can go back in time to find when,
> 	where and how a bug appeared (which makes the "bisect" command,
> 	which both Git and Mercurial have, *the* killer feature of any
> 	SCM).

Rebase is crucial for some open distributed development model, like the
Linux kernel one. People send patches, other people review and critize
them so they get amended and resent. All this *before* the actual commit
is done. Is amazing how bad tend to get the commits when this model is not
encouraged (I see "ooops! forgot to add one file in the previous
commit"-kind of commits everywere and it just make me mad =). Specially
when you want "bisect" to work! That kind of changes don't even compile
and break "bisect"!

> 	Second, Mercurial has three ways to do what "git rebase" does:
> - The first is the Rebase extension, which does the same thing with the same drawbacks;

I have to take a look at it.

> - The second is the Transplant extension, which *copies* the changesets
> instead of moving them, so you keep the old history (you can always use
> "strip" to remove it later if you really want to);

In git you always keep the old history unless you run the gc (or well,
it's ran automatically if you don't configure it otherwise). You can
always make a local branch if you *really really* feel like you must keep
the old history ;)

> - And the third is to simply merge your changes with the incoming changesets with "hg merge".

That's a merge, not a rebase =)

> >and because it
> >supports local branches (I didn't read about how branches are managed in
> >Mercurial yet, but I understand that Mercurial doesn't support local
> >branches).
> 	It does through the LocalBranch extension.

Ok, lots of extensions! =O

> >* Large output goes through a pager by default
> 
> 	I actually don't like that one, but Mercurial has it too with the AutoPager extension.	

If you mean this:
http://bitbucket.org/brodie/autopager/overview/

I just tried it but I get this error:
abort: could not import module encoding!
=/

> >* git add -p 
> 	I've read the help on that one and I still don't understand what it does: According to the help it is the "same as interactive except it's not"???

Is hg record but you with some extra options. Git add -i has even more
options ;)

> >git citool
> 	Available through the qct extension.

Ok, it seems there is Mercurial, and Mercurial+lots of extensions. They
seems to be 2 different SCMs =)

And wait, that an entire third-party application!

> >>>Having a DSCM would make things easier for people that integrates DMDFE in other
> >>>projects than DMD.
> >>	If you say so...
> >Come on! Is easier to pull and merge patches, you don't have to do it by
> >hand! Just do git pull or hg pull you are set!
> 	Well, just do "svn update" and you are set :) DSCMs are useful
> 	when your development follows the "Bazaar" model (*) with lots of
> 	contributors working independently and exchanging their
> 	modifications. They are much less useful if you follow the
> 	"Cathedral" model, with a strict hierarchy and a small number of
> 	actual committers.

svn now nothing about merges, conflicts will be much more common.

> 	I'd say that the main point when choosing between a centralized
> 	and distributed SCM is the number of actual committers, not the
> 	number of users.

I completelly disagree. I wont consider using svn even for personal
projects because it lacks so many features, and is so slow it makes me
want to cry =)

For example, being able to amend patches is a must for me. But we are
getting too much in personal taste here.

> 	For users, pulling the changes from a distributed
> 	system is exactly the same as pulling them from a centralized
> 	repository.

That's not true! DSCM does extremely better job merging than CSCM (at
least Git does). And you can't even maintain your own branch! That's
useless for LDC for example[*].

> 	Again, I'm not really arguing against DSCMs in general here. I'm
> 	mainly saying that there is no point in going for a DSCM later if
> 	we can have a centralized SCM now, since the DSCM won't bring that
> 	many advantages for D anyway.

And I still think you are wrong =)

But anyways, this is getting way too off-topic, and Walter didn't even
talked about it after saying "nice idea" so I think I'll stop posting in
this thread for now.

Thanks for all the nice Mercurial tips, I hope they make my Mercurial
experience a little happier =)

[*] I mean, for LDC, is the same if Walter post raw patches with a nice
comment about what the do or if he use SVN. You can't modify your own copy
of a SVN repo without committing. Having those nice patches with nice
comments are a *huge* step still, and that's why I prefer to have SVN over
nothing, because I know Walter won't post raw patches ever ;)

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Parece McGuevara's o CheDonald's