Source control for all dmd source (Git propaganda =)

["Jérôme M. Berger"]

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).

	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;
- 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);
- And the third is to simply merge your changes with the incoming 
changesets with "hg merge".

> 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.

> And then there are the details, which I mention in another
> post:
> * Syntax highlight in the output of commands (status, diff, log, branch,
>   grep)

	This didn't work out of the box for me on Windows. I haven't tried 
to activate it, so I don't know if it cans.

	Mercurial has it too on Linux. The Windows version will be 
available as soon as I have the time to clean up the patch and send 
it upstream :)

> * Large output goes through a pager by default

	I actually don't like that one, but Mercurial has it too with the 
AutoPager extension.	

> * 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"???

> git citool
> 
	Available through the qct extension.

> I think this is a matter of taste/experience. I find Mercurial much more
> harder to use than Git. Git could be hard to *understand* at first, but
> I swear it's not hard to *use*. Install is trivial (use the package it
> comes with your distribution in Linux or msysgit installer in Windows).
> 
	"Understand at first" and "Use" are almost the same. The only time 
they will differ is if the first masks some extra features that the 
second doesn't have, but this does not seem to be the case here.

>>>> 	Finally, no matter how good it is, TortoiseGIT is not enough (in the same way that TortoiseCVS, TortoiseSVN and TortoiseHg are not enough). You need good 
>>>> command-line support so that you can access it easily from custom tools (for example to generate releases automatically).
>>> You have a good command-line support.
>> 	Maybe you do, but that's not the impression the Git fans here were giving:
>>  - Robert Fraser on win32 support: "git's Win32 support via TortoiseGit is nearly as good as SVN's now"
>>  - All the discussion between BCS, hasen and Daniel Keep on tortoise git.
> 
> TortoiseGIT is not command line =)
> 
	Precisely my point.

>>> 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.

	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. For users, pulling the changes from a distributed system 
is exactly the same as pulling them from a centralized repository.

	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.

		Jerome

(*) 
http://webyes.com.br/wp-content/uploads/ebooks/book_cathedral_bazaar.pdf 


-- 
mailto:jeberger at free.fr
http://jeberger.free.fr
Jabber: jeberger at jabber.fr

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20090603/1cca9fb1/attachment.pgp>