Vincent Ladeuil <[EMAIL PROTECTED]> writes:
> Hi Matthieu,
^^
>>>>>> "Mathieu" == Matthieu Moy <[EMAIL PROTECTED]> writes:
^
(is your mailer automatically adding this spelling mistake to my
name ;-) ?)
> Mathieu> Hi,
>
> <snip/>
>
> Mathieu> I'm migrating some of my project to git, which seems
> Mathieu> to be a really cool version control system. I'll try
> Mathieu> to find some time to see what has to be done here.
>
> Just out of curiosity: AIUI, you migrated from GNU Arch to bzr,
> why are you migrating to git now ?
I have several reasons to migrate away from bzr:
1) Total absence of trust in Canonical. The way they did the baz ->
bzr transition is unacceptable. They actually abandonned Bazaar
1.x's developpment in Jully 2005, in October 2005, the were still
ignoring the bug reports, not working at all on it, but still
letting me wasting my time on it. I spent tens of hours following
the promise that Bazaar was still maintained. In February 2006,
the maintainer posted a mail saying that he was going to release
1.5. They took a year to finally admit that the were not
maintaining Bazaar anymore. The post is here:
https://lists.ubuntu.com/archives/bazaar-old/2006-June/000531.html
my comments are there:
https://lists.ubuntu.com/archives/bazaar-old/2006-July/000535.html
and the maintainers of Bazaar didn't even bother to reply.
They're developping bzr for their internal needs, and they don't
really care about their users.
Now, they're somehow re-writting history by claiming that the word
Bazaar has always referred to bzr:
http://bazaar-vcs.org/Branding?highlight=%28Baz%29
2) Long-term continued existance: Given my level of trust in
Canonical, I don't want to invest in a tool if I don't have
garantee in its future. Git has X.org, the kernel. Mercurial has
OpenSolaris, now Mozilla, ... If the main developpers of Git or
Mercurial take a wrong decision, or cease development, the big
projects using them will manage to get the things right (fork or
so). Bzr didn't manage to convince any big project outside
Canonical, and most bzr developpers are canonical employee.
I don't think there's room for so many VCS in the world. CVS is
dead, Subversion replaces it waiting for a better option, but I
think maybe 2 or 3 will really emerge. Git seems to be part of
these, Mercurial is probably part of them too. I don't see how bzr
would catch up with them.
3) Performance: Bzr has been claiming for months that they would
release 1.0 "soon", "with performance equivalent to the best in the
field.". Since bzr 1.0 was originally planned for the first quarter
of 200_6_, and since bzr is still very far behind Git and
Mercurial, I have great doubts on this promise. I'm not developping
big projects now, so I don't care _so much_, but having the tool
answer immediately to almost any command is still pleasant.
Now, for the advantages of git:
1) Performance. Git is the fastest SCM for most operations. The pack
file format is the smallest in size (having "git repack" a separate
operation from "git commit" allows agressive optimizations in the
way delta-compression is done).
2) Simple and powerful model. In git, you have objects, identified by
their sha-1 sum, and pointers to objects. For example, a revision
in bzr in a commit in git, which contains a message and a pointer
to the tree object, itself pointing to file objects.
3) Some interesting ideas, like the way rename are managed. Git can
identify code movement from a file to another, so, for example,
"git blame" can tell you "this line was originally commited to file
A, and then copied to file B, then moved within this file", ...
4) The design is oriented towards code review, iterative improvements.
Commands like "git rebase" seem interesting to me.
5) "git fsck" makes me feel safe. Given a revision identifier, I can
be sure that my repository contains this revision, and all its
ancestors, with a garantee as strong as sha-1.
That said, bzr still has a few features I miss in git, like
"checkout/bind", dumb protocols like sftp/ftp support, ... But at
least, I want to give git a try on real projects, to get a better idea
of what it can do.
--
Matthieu
_______________________________________________
Dvc-dev mailing list
[email protected]
https://mail.gna.org/listinfo/dvc-dev
