From: Luca <kronos.it@gmail.com>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] qemu Changelog Makefile Makefile.target TODO ae...
Date: Tue, 18 Sep 2007 00:02:12 +0200 [thread overview]
Message-ID: <68676e00709171502y6f3718b5k9d5aed15cf68e7f6@mail.gmail.com> (raw)
In-Reply-To: <1190065596.14938.203.camel@rapid>
On 9/17/07, J. Mayer <l_indien@magic.fr> wrote:
> On Mon, 2007-09-17 at 23:14 +0200, Luca wrote:
> > > > since I mentionned "you should have used Git", I'll repeat:
> > > > this commit was not disruptive to any of the Git users, and will
> > > > never be.
> > > >
> > > > Evolve, or prepare to be assimilated into the Collective...
> > >
> > > Both the qemu.org and the Savannah project page only mention CVS. If
> > > there are better ways to get the code then inform your users how to
> > > use that.
>
> > http://brick.kernel.dk/git/?p=qemu.git;a=summary
> > It's tracking QEMU CVS; you're right that it's not mentioned anywhere
> > on the site (AFAICS).
> > You can also DIY with git-cvsimport; see e.g.
> > http://chneukirchen.org/blog/archive/2006/04/tracking-the-ruby-cvs-with-git.html
>
> Another point is CVS is an industry standard. It has many drawbacks but
> is prooven to do its job as specified in a very reliable way. For now,
> not such a thing for git, afaik. If it ever become the new industry
> standard, after having prooven its reliability and long term stability,
> then you may be able to expect everyone to use it.
> Did anyone has done a long term comparison of CVS and git running on two copies of the
> same production repository and have made sure that any extraction at any
> time of any data (ie, checkout in the present and any date in the past,
> diffs, ...) of the two gives exactly the same result?
Actually CVS doesn't provide _any_ guarantee about data integrity. GIT
does. So...
> Please show me
> such studies and I may reconsider my position... If not, you can always
> use it, closing your eyes and praying for everything to be OK...
...yes, I'm willing to trust GIT over CVS any time ;)
Luca
next prev parent reply other threads:[~2007-09-17 22:02 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-16 21:08 [Qemu-devel] qemu Changelog Makefile Makefile.target TODO ae Thiemo Seufer
2007-09-17 8:08 ` J. Mayer
2007-09-17 8:27 ` Christian MICHON
2007-09-17 9:42 ` J. Mayer
2007-09-17 10:00 ` Johannes Schindelin
2007-09-17 11:19 ` Philip Boulain
2007-09-17 12:18 ` Christian MICHON
2007-09-17 20:59 ` Andreas Färber
2007-09-17 21:14 ` Luca
2007-09-17 21:46 ` J. Mayer
2007-09-17 22:02 ` Luca [this message]
2007-09-18 13:21 ` Thiemo Seufer
2007-09-17 21:30 ` Christian MICHON
2007-09-17 22:47 ` Johannes Schindelin
2007-09-18 16:20 ` Andreas Färber
2007-09-17 9:21 ` Johannes Schindelin
2007-09-17 14:52 ` M. Warner Losh
2007-09-17 13:52 ` Thiemo Seufer
-- strict thread matches above, loose matches on Subject: below --
2007-09-17 23:56 Ben Taylor
2007-09-18 12:49 ` Philip Boulain
2007-09-18 17:05 ` Stefan Weil
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=68676e00709171502y6f3718b5k9d5aed15cf68e7f6@mail.gmail.com \
--to=kronos.it@gmail.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).