Fwd: Re: [Qemu-devel] What does code_copy_enabled do?
Apparently I write in a spamy way. There's no contact for these kinds of issues, so I'm sending this here, sorry. -- Forwarded message -- From: Date: Feb 13, 2008 11:24 AM Subject: RE: Re: [Qemu-devel] What does code_copy_enabled do? To: [EMAIL PROTECTED] MDaemon has identified your message as spam. It will not be delivered. >From : [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject : [***SPAM*** Score/Req: 07.60/07.00] Re: [Qemu-devel] What does code_copy_enabled do? Message-ID: <[EMAIL PROTECTED]> Yes, hits=7.6 required=7.0 tests=BAYES_99, NEW_DOMAIN_EXTENSIONS autolearn=no version=2.63 *** * 2.2 NEW_DOMAIN_EXTENSIONS BODY: Possible registry spammer * 5.4 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.] : Message contains [1] file attachments -- Felipe Contreras Return-path: <[EMAIL PROTECTED]> Received: from lists.gnu.org ([199.232.76.165]) by fidonet.org.il (survey.co.il [213.8.108.3]) (MDaemon.PRO.v7.1.1.R) with ESMTP id md50001626354.msg for <[EMAIL PROTECTED]>; Wed, 13 Feb 2008 11:24:30 +0200 Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JPDn5-0003KF-Ut for [EMAIL PROTECTED]; Wed, 13 Feb 2008 04:20:32 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JPDlB-0003JV-3W for qemu-devel@nongnu.org; Wed, 13 Feb 2008 04:18:33 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JPDl9-0003J5-LT for qemu-devel@nongnu.org; Wed, 13 Feb 2008 04:18:31 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JPDl9-0003Iw-EA for qemu-devel@nongnu.org; Wed, 13 Feb 2008 04:18:31 -0500 Received: from py-out-1112.google.com ([64.233.166.183]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from <[EMAIL PROTECTED]>) id 1JPDl9-0006cl-Mq for qemu-devel@nongnu.org; Wed, 13 Feb 2008 04:18:31 -0500 Received: by py-out-1112.google.com with SMTP id u52so7693804pyb.10 for ; Wed, 13 Feb 2008 01:18:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=KQx+/pVAbT/9t+BlLTXsCDpXQSe+v191wORcWepOylI=; b=o1S42OMTdTGlLMb2iCw0kymxw1lDwj6VjjY5mpdEZUtxLfsXzmK8CiCc3c4hhYlcnXF4/15IPNfcWUsbWbiXJJtFNPIq3A5qSMi/qO5R4eiq57sE1cx/jWqyhsv0BlVhP0blIZwRblJ6RJJHGFHLNnvAhSTZGLyzqHza/aeF3+g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=lEU66Yqv40Yu6I0JYcixmFXoMzt8hNkvt85rqfZNcoeFYQD4I7jzEjUvaEOM2YHn1YHyPk433x8CNXITlEK012m6/i0wLBC46o39OYRRR0KmSZVDjzCR8IoxWExu1UX4/4zwFBQlsV1Au+v3XhzRD0l4vfuOJ34lDKw0MBxbaN0= Received: by 10.141.22.1 with SMTP id z1mr1684092rvi.67.1202894309416; Wed, 13 Feb 2008 01:18:29 -0800 (PST) Received: by 10.140.188.7 with HTTP; Wed, 13 Feb 2008 01:18:29 -0800 (PST) Message-ID: <[EMAIL PROTECTED]> Date: Wed, 13 Feb 2008 11:18:29 +0200 From: "Felipe Contreras" <[EMAIL PROTECTED]> To: "Rob Landley" <[EMAIL PROTECTED]> Subject: [***SPAM*** Score/Req: 07.60/07.00] Re: [Qemu-devel] What does code_copy_enabled do? In-Reply-To: <[EMAIL PROTECTED]> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 2) Cc: Ian Jackson <[EMAIL PROTECTED]>, qemu-devel@nongnu.org, Blue Swirl <[EMAIL PROTECTED]>, Paul Brook <[EMAIL PROTECTED]> X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>, <mailto:[EMAIL PROTECTED]> List-Archive: <http://lists.gnu.org/pipermail/qemu-devel> List-Post: <mailto:qemu-devel@nongnu.org> List-Help: <mailto:[EMAIL PROTECTED]> List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>, <mailto:[EMAIL PROTECTED]> Sender: [EMAIL PROTECTED] Errors-To: [EMAIL PROTECTED] X-MDRcpt-To: [EMAIL PROTECTED] X-Rcpt-To: [EMAIL PROTECTED] X-MDRemoteIP: 199.232.76.165 X-Return-Path: [EMAIL PROTECTED] X-MDaemon-Deliver-To: [EMAIL PROTECTED] X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on survey1 X-Spam-Report: * 2.2 NEW_DOMA
Re: [Qemu-devel] What does code_copy_enabled do?
On Feb 13, 2008 10:22 AM, Rob Landley <[EMAIL PROTECTED]> wrote: > On Tuesday 12 February 2008 05:57:18 Ian Jackson wrote: > > hg is much better. OTOH it does have one severe problem: it expects > > you to check in before merging, which is the opposite of what cvs > > users expect. A cvs refugee, or anyone working on a project whose > > leaders don't like merge changesets (yes, they exist) will notice new > > changes upstream and decide to merge them into their current tree with > > `hg pull -u', which is the equivalent of `cvs update'. > > Notice how -u is an option, and the default is _not_ update your current > working state? If supplying an option has a behavior you don't like, which > it won't do if you leave the option off, where's the problem? > > (And one thing hg won't _ever_ do is throw <<< style crap into your source > code when you pull, which you're implying is somehow desirable.) > > > However, that > > rune's handling of merge conflicts is catastrophically bad and likely > > to lead to the working tree being effectively destroyed, possibly > > losing a great deal of work. > > This is a design issue. Collisions happend during a merge, not during a > checkin. In a distributed source control system, a checkin always happens > against a known state. Therefore, if you do a pull from outside you're > either doing an implicit merge (-u) or you're creating a new branch (if you > do a checkin against an old version of the repository after pulling). > > It's not really a user interface issue, it's a difference between how > distributed and centralized source control systems work. > > > As I've said, I think there is no point switching from cvs to svn. > > It's true that cvs's lack of the concept of a changeset is a serious > > problem and makes mirroring a cvs repository something of a challenge. > > However, there is already software to reconstruct changesets from cvs > > logs, and provided the cvs users use cvs in a sane and predictable way > > (which current qemu upstream do) those conversion tools do work. > > Modulo being buggy and complicated. But in theory they work, yes. The > current git mirrors are maintained from them, and I can limp along with that > indefinitely. > > > What should those of us who want to collaborate using a drcs (so that > > we can share our work-in-progress patches and generally avoid blocking > > on upstream) do in the meantime ? > > Simple: > > A) Pick a repository as your upstream. Doesn't matter which, just as long as > you agree. > > or, > > B) Send patches around ala cherry-pick, which is what you have to do to send > them upstream anyway. > > For the first 10 years Linus Torvalds's only source control system was the > periodic release of tarball snapshots of his personal source tree. Even CVS > is only slightly worse than that. > > > Having a private mirror of a drcs is all well and good but no-one can > > pull from anyone else because each cvs/svn->drcs conversion yields an > > incompatible history. > > *shrug* I'll live. > > > At the very least we need one drcs branch containing only changes from > > the upstream cvs. It has to be incrementally updated, automatically > > and frequently, and generally be well maintained. > > Already exists. > > > Most of the potential users seem to be fans of git which is fine by > > me. > > No, most of the existing mirrors are git based, and the potential users are > lazy enough to use what's in front of us. I note that the most popular > cvs->hg conversion tool (tailor) had a bug in it for most of last year, due > to depending on a package (cvsps) that was broken in Ubuntu 7.04. > > Mercurial itself had a new "convert extension" merged into mainline a few > months ago, so it should now have cvs->hg functionality built in. But it's > brand new and I haven't fiddled with it yet. > > Personally, I'd much rather have a mercurial repository, but I'm lazy enough > to live with git if it's there. It is considerably more complicated than > mercurial, and has a horrible user interface, but it still means I don't have > to deal with CVS directly. I don't think these kind of discussions are productive. If someone is interested in pushing their favorite dcms they should do some kind of study and publish it so other projects can benefit and not have these discussions over and over. Personally, anything other than git or SVN would make things difficult for me. I think SVN is a good option. Easy to move from CVS, easy to use from any dcms. I don't think anyone would prefer the status-quo against SVN. Picking a dcms on the other hand would probably cause discomfort on other dcms's fans and people that don't care about the cms. Best regards. -- Felipe Contreras
Re: [Qemu-devel] What does code_copy_enabled do?
On Tuesday 12 February 2008 05:57:18 Ian Jackson wrote: > hg is much better. OTOH it does have one severe problem: it expects > you to check in before merging, which is the opposite of what cvs > users expect. A cvs refugee, or anyone working on a project whose > leaders don't like merge changesets (yes, they exist) will notice new > changes upstream and decide to merge them into their current tree with > `hg pull -u', which is the equivalent of `cvs update'. Notice how -u is an option, and the default is _not_ update your current working state? If supplying an option has a behavior you don't like, which it won't do if you leave the option off, where's the problem? (And one thing hg won't _ever_ do is throw <<< style crap into your source code when you pull, which you're implying is somehow desirable.) > However, that > rune's handling of merge conflicts is catastrophically bad and likely > to lead to the working tree being effectively destroyed, possibly > losing a great deal of work. This is a design issue. Collisions happend during a merge, not during a checkin. In a distributed source control system, a checkin always happens against a known state. Therefore, if you do a pull from outside you're either doing an implicit merge (-u) or you're creating a new branch (if you do a checkin against an old version of the repository after pulling). It's not really a user interface issue, it's a difference between how distributed and centralized source control systems work. > As I've said, I think there is no point switching from cvs to svn. > It's true that cvs's lack of the concept of a changeset is a serious > problem and makes mirroring a cvs repository something of a challenge. > However, there is already software to reconstruct changesets from cvs > logs, and provided the cvs users use cvs in a sane and predictable way > (which current qemu upstream do) those conversion tools do work. Modulo being buggy and complicated. But in theory they work, yes. The current git mirrors are maintained from them, and I can limp along with that indefinitely. > What should those of us who want to collaborate using a drcs (so that > we can share our work-in-progress patches and generally avoid blocking > on upstream) do in the meantime ? Simple: A) Pick a repository as your upstream. Doesn't matter which, just as long as you agree. or, B) Send patches around ala cherry-pick, which is what you have to do to send them upstream anyway. For the first 10 years Linus Torvalds's only source control system was the periodic release of tarball snapshots of his personal source tree. Even CVS is only slightly worse than that. > Having a private mirror of a drcs is all well and good but no-one can > pull from anyone else because each cvs/svn->drcs conversion yields an > incompatible history. *shrug* I'll live. > At the very least we need one drcs branch containing only changes from > the upstream cvs. It has to be incrementally updated, automatically > and frequently, and generally be well maintained. Already exists. > Most of the potential users seem to be fans of git which is fine by > me. No, most of the existing mirrors are git based, and the potential users are lazy enough to use what's in front of us. I note that the most popular cvs->hg conversion tool (tailor) had a bug in it for most of last year, due to depending on a package (cvsps) that was broken in Ubuntu 7.04. Mercurial itself had a new "convert extension" merged into mainline a few months ago, so it should now have cvs->hg functionality built in. But it's brand new and I haven't fiddled with it yet. Personally, I'd much rather have a mercurial repository, but I'm lazy enough to live with git if it's there. It is considerably more complicated than mercurial, and has a horrible user interface, but it still means I don't have to deal with CVS directly. Rob -- "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson.
Re: [Qemu-devel] What does code_copy_enabled do?
Johannes Schindelin writes ("Re: [Qemu-devel] What does code_copy_enabled do?"):
> If you mean the one at repo.or.cz and the one at kernel.dk, no. They
> contain exactly the same history.
You're right. I hadn't checked. My own mirror generated with
git-cvsimport is incompatible with both of course, but those two are
in fact compatible.
How is that achieved ? Is one of them a mirror of the other ? Who
runs them ? (Why do I have to asking about this on a mailing list
when there ought to be a web page telling me?)
Ian.
Re: [Qemu-devel] What does code_copy_enabled do?
Hi,
On Tue, 12 Feb 2008, Ian Jackson wrote:
> Johannes Schindelin writes ("Re: [Qemu-devel] What does code_copy_enabled
> do?"):
> > On Tue, 12 Feb 2008, Ian Jackson wrote:
> > > At the very least we need one drcs branch containing only changes
> > > from the upstream cvs. It has to be incrementally updated,
> > > automatically and frequently, and generally be well maintained.
> >
> > FWIW on this very list, there have been enough hints where you can
> > find such a thing, and it is not even private.
>
> I've seen two people mention git mirror urls.
>
> They contain different incompatible histories because they're
> generated separately.
If you mean the one at repo.or.cz and the one at kernel.dk, no. They
contain exactly the same history.
> The problem isn't that we don't have a git mirror of cvs. The problem
> is that we need to have exactly _one_.
I do not begin to understand why.
Ciao,
Dscho
Re: [Qemu-devel] What does code_copy_enabled do?
Johannes Schindelin writes ("Re: [Qemu-devel] What does code_copy_enabled do?"):
> On Tue, 12 Feb 2008, Ian Jackson wrote:
> > At the very least we need one drcs branch containing only changes from
> > the upstream cvs. It has to be incrementally updated, automatically
> > and frequently, and generally be well maintained.
>
> FWIW on this very list, there have been enough hints where you can find
> such a thing, and it is not even private.
I've seen two people mention git mirror urls.
They contain different incompatible histories because they're
generated separately. The problem isn't that we don't have a git
mirror of cvs. The problem is that we need to have exactly _one_.
And if we're going to have exactly one then it has to be reliable.
That doesn't mean some mirror url found in a search engine.
It means a site whose operators we know, and whose operators have
shown some evidence of a commitment to keep it working, and whom we
can contact them if it breaks. It means that the the update frequency
is published. It means someone who has some connection with the qemu
community so that we can expect them to care about it.
If we have that then everyone can expect to pull from it and not
commit to a workflow that might suddenly become untenable.
Ian.
Re: [Qemu-devel] What does code_copy_enabled do?
Hi, On Tue, 12 Feb 2008, Ian Jackson wrote: > * In the meantime, or if upstream decide not to, what is the best way >for non-upstream contributors to collaborate with each other ? > > [...] > > What should those of us who want to collaborate using a drcs (so that we > can share our work-in-progress patches and generally avoid blocking on > upstream) do in the meantime ? > > Having a private mirror of a drcs is all well and good but no-one can > pull from anyone else because each cvs/svn->drcs conversion yields an > incompatible history. > > At the very least we need one drcs branch containing only changes from > the upstream cvs. It has to be incrementally updated, automatically > and frequently, and generally be well maintained. FWIW on this very list, there have been enough hints where you can find such a thing, and it is not even private. Ciao, Dscho
Re: [Qemu-devel] What does code_copy_enabled do?
Hi, Am 12.02.2008 um 12:15 schrieb Johannes Schindelin: On Tue, 12 Feb 2008, Paul Brook wrote: Any news on the possible cvs->svn migration? To be perfectly honest, IMO there is little point moving an existing project from CVS to SVN. I disagree. CVS has several fairly fundamental flaws (no global revision IDs, unable to move files, and more subtle problems with branches/tags). SVN fixes these, and in most cases works as a direct drop-in replacement for CVS. Granted, SVN is better than CVS. But they did not even begin to tackle the fundamental shortcomings. While I can see that distributed revision control systems do enable some interesting possibilities, there's certainly no clear winner. There might not be a clear winner, but that's only because they are about equally "good". Using this argument to choose an inferiour system, such as svn, which is not only slower, bigger, has a lousy tagging/annotating/merging support, but actively discourages good workflows, is, uhm, not so wise. Currently SVN is much more widely supported than Git, which seem to be the only two alternative options here at Savannah. All of them seem to have have fairly serious issues with either usability, portability, scalability, and/or require learning a whole new workflow. Note that he said 'either'. Usability: uhm, no. There are enough short tutorials to show that Hg and Git are pretty easy to learn. Portability: uhm, no. Hg never had an issue there, Git no longer does. Mercurial has a hard dependency on Python; Git only an optional dependency on Tcl/Tk for their GUI. SVN tarballs don't need either (only SVN from SVN needs Perl+Python). Whole new workflow: uhm, no. You do not _need_ to use the bells and whistles of Hg or Git, if you really are that resistant. Johannes, just navigating around your Git repository is "hard" for someone not comfortable with git. The git pull etc. part is easy compared to that. The Subversion URLs make it much more obvious to find branches; something that's really missing in our CVS and recently forced to fork a stable branch elsewhere. But if you have 5 options, 2 of them just shine, and the other 3 are bad, do you really pick a bad apple, because "there is no best"? This is pointless and untrue. I agree with Paul that SVN is better than CVS and so did you above; so there's no black-and-white or 2:3 really. And may I add that for SVN there's apparently also an SVK in addition to the already mentioned git/hg interoperability. (haven't used it personally though) The really interesting question I see is whether a move from CVS to SVN here at Savannah would allow the CVS history to be imported using said heuristics. If no, then I assume it's out of the question anyway. Andreas
Re: [Qemu-devel] What does code_copy_enabled do?
It seems to me that there are two questions here: * Should the CVS for the upstream repository be replaced with something else ? * In the meantime, or if upstream decide not to, what is the best way for non-upstream contributors to collaborate with each other ? The answer to the first question is unambiguously `yes', I think. There are approximately five serious contenders for the replacement: svn, darcs, hg, git, bzr. Switching now to any of the drcs's would be unlikely to be regretted in the medium to long term. I haven't used darcs, but I'm in a perhaps slightly unusual position of having used all of hg, git, bzr and cvs. (I've touched svn too but haven't done anything at all complicated with it, like branching.) I think that for cvs refugees, the right answer is bzr. [1][2] bzr is strictly better than cvs in almost every respect. In particular, refugees from cvs and svn will find it easy to get to grips with. To a large extent you can just say `bzr whatever' instead of `cvs whatever', confident that it will do the right thing - and guessing is safe because even if that was the wrong rune it generally won't do something crazy and make a hideous mess. The areas where bzr is comparatively weak (performance, advanced forms of merging, lightweight branching, etc.) are already worse in cvs. On the other hand, git's and hg's weaknesses are clear regressions from cvs. git's user interface is frankly appalling. It's very functional and some day I hope to see a wrapper which makes git look more like the way everyone expects an rcs to work, and avoids blowing off one's leg. In the meantime I do use it myself but I'm wary of pushing it. hg is much better. OTOH it does have one severe problem: it expects you to check in before merging, which is the opposite of what cvs users expect. A cvs refugee, or anyone working on a project whose leaders don't like merge changesets (yes, they exist) will notice new changes upstream and decide to merge them into their current tree with `hg pull -u', which is the equivalent of `cvs update'. However, that rune's handling of merge conflicts is catastrophically bad and likely to lead to the working tree being effectively destroyed, possibly losing a great deal of work. As I've said, I think there is no point switching from cvs to svn. It's true that cvs's lack of the concept of a changeset is a serious problem and makes mirroring a cvs repository something of a challenge. However, there is already software to reconstruct changesets from cvs logs, and provided the cvs users use cvs in a sane and predictable way (which current qemu upstream do) those conversion tools do work. svn's support for branches is even worse than that of cvs's; this is frankly astonishing given how painful branches are to work with in cvs and how long this has been known to be a serious problem. But really my point is that change is painful so if we're going to try to switch to a new revision control system, with all of the learning, messing about with new software, cursing, and so on, we should try to get as much benefit as we can for our effort. Anyone who switches to svn now will, I think, regret it in another few years. The pressure to switch to a drcs will not go away. On to the second question: What should those of us who want to collaborate using a drcs (so that we can share our work-in-progress patches and generally avoid blocking on upstream) do in the meantime ? Having a private mirror of a drcs is all well and good but no-one can pull from anyone else because each cvs/svn->drcs conversion yields an incompatible history. At the very least we need one drcs branch containing only changes from the upstream cvs. It has to be incrementally updated, automatically and frequently, and generally be well maintained. Most of the potential users seem to be fans of git which is fine by me. If there is someone who knows git better than me and would like to provide a properly supported regularly updated git mirror of the upstream cvs then I would be happy to use and pull from it. Otherwise I would be quite happy to maintain such a thing on www.xen.org (the website for the Open Source Xen). Ian. (I hope the Reply-To munging hasn't caused anyone to be dropped from the CC; I've done a quick check but please forgive me if I missed one.) [1] Full disclosure: Not everyone may be aware that I spent a couple of years working for Canonical as an Ubuntu developer; I left in November. I didn't work on bzr. IMO my recommendation of bzr is best regarded as despite my relationship with Canonical, rather than because of it. [2] Some people think that bzr has some kind of dependency on Launchpad. This is not the case. If it did I wouldn't be recommending it.
Re: [Qemu-devel] What does code_copy_enabled do?
> : > > Any news on the possible cvs->svn migration? > : > > : > To be perfectly honest, IMO there is little point moving an existing > : > project from CVS to SVN. > : > : I disagree. CVS has several fairly fundamental flaws (no global revision > : IDs, unable to move files, and more subtle problems with branches/tags). > : SVN fixes these, and in most cases works as a direct drop-in replacement > : for CVS. > > FreeBSD is moving from CVS to SVN for these reasons. Just to second "M. Warner Losh": we moved Valgrind from CVS to SVN about 3.5 years ago and it was an excellent thing to do. It is not true to say there is no advantage over CVS -- the global revision IDs, the ability to rename files, and a simpler branching/tagging model are all big advantages. And the fact that it is more-or-less conceptually a drop-in replacement makes it easy for people to make the migration. Sure, Valgrind is a tiny project compared to FreeBSD. But we gain those advantages nonetheless. J
Re: [Qemu-devel] What does code_copy_enabled do?
Hi, I did not really want to continue this discussion, but then, I really cannot let certain statements slip by. *sigh* On Tue, 12 Feb 2008, Paul Brook wrote: > > > Any news on the possible cvs->svn migration? > > > > To be perfectly honest, IMO there is little point moving an existing > > project from CVS to SVN. > > I disagree. CVS has several fairly fundamental flaws (no global > revision IDs, unable to move files, and more subtle problems with > branches/tags). SVN fixes these, and in most cases works as a direct > drop-in replacement for CVS. Granted, SVN is better than CVS. But they did not even begin to tackle the fundamental shortcomings. > While I can see that distributed revision control systems do enable some > interesting possibilities, there's certainly no clear winner. There might not be a clear winner, but that's only because they are about equally "good". Using this argument to choose an inferiour system, such as svn, which is not only slower, bigger, has a lousy tagging/annotating/merging support, but actively discourages good workflows, is, uhm, not so wise. > All of them seem to have have fairly serious issues with either > usability, portability, scalability, and/or require learning a whole new > workflow. Usability: uhm, no. There are enough short tutorials to show that Hg and Git are pretty easy to learn. Portability: uhm, no. Hg never had an issue there, Git no longer does. Scalability: I do beg your pardon? Hg might not be as scalable as Git, but SVN and CVS positively *suck* in that respect. Whole new workflow: uhm, no. You do not _need_ to use the bells and whistles of Hg or Git, if you really are that resistant. You can just update & add & commit as before (with Git, you just need to substitute "pull" for "update"). The only difference is that you push to the "official" server from time to time. > I'm sure advocates of each system will claim that their system is the > "best", but I remain unconvinced. I'm sure you remain unconvinced, if only to make a point. As for "best": I would not claim that either Hg or Git are "best". My preference is clear. But if you have 5 options, 2 of them just shine, and the other 3 are bad, do you really pick a bad apple, because "there is no best"? > SVN may not have the bells and whistles of some of the more exotic > systems. However it is is well tested proven technology, and IMO > universally better than CVS. It is well tested and proven, granted. As a version control system. But in terms of a source code management tool, it just leaves to be desired. Ciao, Dscho
Re: [Qemu-devel] What does code_copy_enabled do?
In message: <[EMAIL PROTECTED]> Paul Brook <[EMAIL PROTECTED]> writes: : > > Any news on the possible cvs->svn migration? : > : > To be perfectly honest, IMO there is little point moving an existing : > project from CVS to SVN. : : I disagree. CVS has several fairly fundamental flaws (no global revision IDs, : unable to move files, and more subtle problems with branches/tags). : SVN fixes these, and in most cases works as a direct drop-in replacement for : CVS. FreeBSD is moving from CVS to SVN for these reasons. : While I can see that distributed revision control systems do enable some : interesting possibilities, there's certainly no clear winner. All of them : seem to have have fairly serious issues with either usability, portability, : scalability, and/or require learning a whole new workflow. I'm sure : advocates of each system will claim that their system is the "best", but I : remain unconvinced. Well, svn now has svn to hg and svn to git gateways, so really it caters to all comers... Warner
Re: Git/SVN/CVS? was Re: [Qemu-devel] What does code_copy_enabled do?
On Monday 11 February 2008 15:28:17 Johannes Schindelin wrote: > Hi, > > On Mon, 11 Feb 2008, Rob Landley wrote: > > I've been using git://git.kernel.dk/data/git/qemu.git although I > > personally prefer mercurial. (It's easier to learn and to use, you get > > the web viewer for free, etc.) > > I really grow tired of people perpetuating how "easy" Mercurial is, > without substantiating it. And the macintosh has a nicer desktop than Gnome, too. :P > Granted, git _used_ to be more difficult, but > now? No, really. I wrote "http://kernel.org/doc/local/git-quick.html";, so I'm not speakign entirely from ignorance when I say that Mercurial is way the heck easier to set up and to use. In mercurial, the human readable web repository viewer and the server you pull from are the same thing (and part of the same package). They're different packages in git, set up differently, and live at arbitrarily different URLs such that knowing where to pull from doesn't let you know where a web repository viewer is (or even if there _is_ one, since it's a lot of extra work to set up in git but comes free in mercurial). There's also no mercurial equivalent to the "git update-server-info" comand because it doesn't need one, and if you're behind a firewall that only allows http access you can pull from mercurial but not from git. Also, since the mercurial repository uses apache as its server just use https:// and you get encryption for free, while git has to reimplement all that. You never have to "pack" or "git gc" a mercurial repository. You don't have to install a seperate documentation package in order for "hg help command" to work. The mercurial command syntax doesn't vary wildly depending on which version you have installed, in git it's totally different before 1.5.0 and after... Shall I go on? I dunno an archive for the users at kernel.org mailing list but the vast majority of the traffic is "strange, subtle, and painful things that can go wrong with git". (It's not a high traffic list, but still.) That said, it's the source control system the kernel guys use, and it _is_ the same basic concepts as any other distributed SCM (with a horrible user interface). I don't _object_ to using it, I just don't prefer it. > The biggest obstacle to using a distributed VCS is that many people do not > grasp, and indeed do not even care about, the concept of a distributed > VCS. For me, going from svn to hg was less pain than going from cvs to svn had been. I like mercurial because going "hg log -v", or "hg update -r 12345" is an entirely local operation that doesn't have to go out on the network. I can tell mercurial to spit out a tarball of any arbitrary historical version (or just put it in a directory directly), again without waiting for access to a server and hoping it's up. You get darn spoiled by that, really quick. (And this doesn't even count the maintainer-only stuff like being able to do checkins on plane flights or long car trips. And said checkin taking a fraction of a second to commit, and _never_ having a conflict during the commit stage.) You don't have to worry about new concepts until you want to use branching and merging, which I really don't much. > That's perfectly fine with me, if you don't want to use a distributed > tool, I do not want to force it down your throat. FWIW I am happily using > git on top of CVS, thankyouverymuch. *shrug* Now that the git mirror I use is updating again, I admit my motivation on this topic's dried up a bit. :) > Ciao, > Dscho Rob -- "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson.
Re: [Qemu-devel] What does code_copy_enabled do?
> > Any news on the possible cvs->svn migration? > > To be perfectly honest, IMO there is little point moving an existing > project from CVS to SVN. I disagree. CVS has several fairly fundamental flaws (no global revision IDs, unable to move files, and more subtle problems with branches/tags). SVN fixes these, and in most cases works as a direct drop-in replacement for CVS. While I can see that distributed revision control systems do enable some interesting possibilities, there's certainly no clear winner. All of them seem to have have fairly serious issues with either usability, portability, scalability, and/or require learning a whole new workflow. I'm sure advocates of each system will claim that their system is the "best", but I remain unconvinced. SVN may not have the bells and whistles of some of the more exotic systems. However it is is well tested proven technology, and IMO universally better than CVS. Paul
Re: Git/SVN/CVS? was Re: [Qemu-devel] What does code_copy_enabled do?
Hi, On Mon, 11 Feb 2008, Rob Landley wrote: > I've been using git://git.kernel.dk/data/git/qemu.git although I > personally prefer mercurial. (It's easier to learn and to use, you get > the web viewer for free, etc.) I really grow tired of people perpetuating how "easy" Mercurial is, without substantiating it. Granted, git _used_ to be more difficult, but now? No, really. The biggest obstacle to using a distributed VCS is that many people do not grasp, and indeed do not even care about, the concept of a distributed VCS. That's perfectly fine with me, if you don't want to use a distributed tool, I do not want to force it down your throat. FWIW I am happily using git on top of CVS, thankyouverymuch. Ciao, Dscho
Re: [Qemu-devel] What does code_copy_enabled do?
On Feb 11, 2008 10:38 PM, Johannes Schindelin <[EMAIL PROTECTED]> wrote: > Hi, > > On Mon, 11 Feb 2008, Felipe Contreras wrote: > > > The advantage of using SVN is that most drcs play along with it quite > > decently. Something that doesn't happen with CVS. > > So you're saying in order to use a DVCS you would need to switch to a > CVCS? I'm saying * > CVS. Even SVN would be fine. BTW, I found the issue, it's on "linux-user/mmap.c" :) -- Felipe Contreras
Re: [Qemu-devel] What does code_copy_enabled do?
On Monday 11 February 2008 14:38:42 Johannes Schindelin wrote: > Hi, > > On Mon, 11 Feb 2008, Felipe Contreras wrote: > > The advantage of using SVN is that most drcs play along with it quite > > decently. Something that doesn't happen with CVS. > > So you're saying in order to use a DVCS you would need to switch to a > CVCS? No, you need to switch _off_ of CVS. CVS hasn't got the concept of "changesets". You can treat a real CVCS as a DVCS that' s never branched, just a linear series of changesets with no merge nodes. But CVS _isn't_ a real CVCS. It's not a series of changesets, it's a bunch of separately tracked files. You know how a single patch can touch a dozen different files? CVS doesn't understand that. Its dumber than the "patch" program. In CVS, every single file stands alone, its history unrelated to any of the others. Out of sheer self-preservation, most CVS users check in changes to lots of different files at once, with identical comments, so you can go back later and match changes up by timestamp and check that the comments match. But this is just a heuristic, dependent on the behavior of the users, and it only sort of works at the best of times because unless your CVS server is infinitely fast, the timestamps won't be _identical_ but just _close_. How close is close enough? Don't go there. (I tried to write such a script once. It hurt.) But having to do data mining in order to detect changesets is an evil specialized black art, it breaks easily, and generally you want to convert up to at least something that understands changesets and NEVER LOOK BACK. > Puzzled, > Dscho Rob -- "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson.
Re: Git/SVN/CVS? was Re: [Qemu-devel] What does code_copy_enabled do?
On Saturday 09 February 2008 10:49:49 Johannes Schindelin wrote: > Hi, > > On Sat, 9 Feb 2008, Felipe Contreras wrote: > > Right now I can't use qemu because a bug introduced in the last months > > and with git-bisect I probably would be able to fix it myself. > > Just clone git://repo.or.cz/qemu.git, then. I've been using git://git.kernel.dk/data/git/qemu.git although I personally prefer mercurial. (It's easier to learn and to use, you get the web viewer for free, etc.) The thing is, git and mercurial are roughly equivalent, they're both distributed source control systems and you can losslessly convert from one to the other and back again, because they have all the same metadata. (See http://kernel.org/hg/linux-2.6 as an example of a mercurial mirror of a git repository.) But the difference between centralized source control and distributed source control is huge. The distributed ones store more information. This means you can convert losslessly convert from svn->hg, but if you convert from hg->svn you lose information. (So if you convert from hg->svn and then back from svn->hg, you have a different mercurial repository, and pulling from the original would be a bad idea because it would think it had lots of duplicate changes.) And of course CVS isn't even a full fledged centralized repository, it's an ancient holdover from the 1980's that doesn't even have the concept of "changesets". (In cvs, changes are tracked in individual files. Changes that touch multiple files at the same time have to be collated after the fact by comparing timestamps and hoping the descriptions match up. This is a brittle heuristic at best; CVS hasn't got this _concept_. Doing a binary search for the change that introduced a bug is amazingly painful with CVS, and even proposing tracking renames violates the design assumptions. Even patch knows how to touch more than one file at a time; CVS does not.) It is possible to use a distributed source control system as if it were a centralized source control system. Just accept all changes as patches, never pulling directly from any other trees. And thus you can hold off on learning new distributed source control concepts indefinitely. > Hth, > Dscho Rob -- "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson.
Re: [Qemu-devel] What does code_copy_enabled do?
Hi, On Mon, 11 Feb 2008, Felipe Contreras wrote: > The advantage of using SVN is that most drcs play along with it quite > decently. Something that doesn't happen with CVS. So you're saying in order to use a DVCS you would need to switch to a CVCS? Puzzled, Dscho
Re: [Qemu-devel] What does code_copy_enabled do?
On Feb 11, 2008 5:52 PM, Ian Jackson <[EMAIL PROTECTED]> wrote:
> Rob Landley writes ("Re: [Qemu-devel] What does code_copy_enabled do?"):
> > Any news on the possible cvs->svn migration?
>
> To be perfectly honest, IMO there is little point moving an existing
> project from CVS to SVN. SVN has better support for renames, and a
> few other advantages, but branching is still pretty catastrophic.
>
> Any of the currently popular drcs's would be a big improvement. In
> particular it would make it much easier to do development on changes
> that don't want to go in CVS mainline for any reason.
The advantage of using SVN is that most drcs play along with it quite
decently. Something that doesn't happen with CVS.
--
Felipe Contreras
Re: [Qemu-devel] What does code_copy_enabled do?
Johannes Schindelin writes ("Re: [Qemu-devel] What does code_copy_enabled do?"):
> Now, that is funny. You quote me, and you quote Rob, but culled both of
> us from the Cc list.
How strange. I definitely didn't mean to do that, sorry.
...tests...
This is the fault of the Reply-To munging.
Ian.
Re: [Qemu-devel] What does code_copy_enabled do?
Hi,
On Mon, 11 Feb 2008, Ian Jackson wrote:
> Johannes Schindelin writes ("Re: Git/SVN/CVS? was Re: [Qemu-devel] What does
> code_copy_enabled do?"):
> > Just clone git://repo.or.cz/qemu.git, then.
>
> Rob Landley writes ("Re: [Qemu-devel] What does code_copy_enabled do?"):
> > ... the git mirror I follow (git://git.kernel.dk/data/git/qemu.git) ...
Now, that is funny. You quote me, and you quote Rob, but culled both of
us from the Cc list.
Re: [Qemu-devel] What does code_copy_enabled do?
Rob Landley writes ("Re: [Qemu-devel] What does code_copy_enabled do?"):
> Any news on the possible cvs->svn migration?
To be perfectly honest, IMO there is little point moving an existing
project from CVS to SVN. SVN has better support for renames, and a
few other advantages, but branching is still pretty catastrophic.
Any of the currently popular drcs's would be a big improvement. In
particular it would make it much easier to do development on changes
that don't want to go in CVS mainline for any reason.
Ian.
Re: [Qemu-devel] What does code_copy_enabled do?
Johannes Schindelin writes ("Re: Git/SVN/CVS? was Re: [Qemu-devel] What does
code_copy_enabled do?"):
> Just clone git://repo.or.cz/qemu.git, then.
Rob Landley writes ("Re: [Qemu-devel] What does code_copy_enabled do?"):
> ... the git mirror I follow (git://git.kernel.dk/data/git/qemu.git) ...
Ideally it would be good for those of us who don't like CVS, and who
want to be a bit more profligate with accepting patches, to be able to
pull from each others' trees.
As I understand it that really means at the very least that there
ought to be one official git tree mirrored from CVS.
I assume that all of these mirrors are made using git-cvsimport in the
most usual way ? The associated websites are a bit sparse. It would
be nicer, if we were going to have something to base our work on, to
have a repository which is updated by cron and publicly available.
I'd be happy to either use an existing mirror or to set one up.
Ian.
Re: Git/SVN/CVS? was Re: [Qemu-devel] What does code_copy_enabled do?
Hi, On Sat, 9 Feb 2008, Felipe Contreras wrote: > Right now I can't use qemu because a bug introduced in the last months > and with git-bisect I probably would be able to fix it myself. Just clone git://repo.or.cz/qemu.git, then. Hth, Dscho
Re: Git/SVN/CVS? was Re: [Qemu-devel] What does code_copy_enabled do?
On Feb 9, 2008 2:45 PM, Johannes Schindelin <[EMAIL PROTECTED]> wrote: > Hi, > > > On Sat, 9 Feb 2008, Blue Swirl wrote: > > > On 2/8/08, Rob Landley <[EMAIL PROTECTED]> wrote: > > > On Thursday 07 February 2008 21:52:33 Paul Brook wrote: > > > > On Friday 08 February 2008, Rob Landley wrote: > > > > > Grepping through the source code, I can find 3 places where this > > > > > global > > > > > variable is set (it's initialized to a default value of 1, there's > > > > > a "no-code-copy" command line option that sets it to zero, and then it > > > > > shows up in the test suite once). What I can't find is any code ever > > > > > actually checking or using the value put into this variable > > > > > > > > It got ripped out a while back. > > > > > > Any news on the possible cvs->svn migration? I'd submit a cleanup > > > patch to rip out the remaining traces of code_copy_enabled, but the > > > git mirror I follow (git://git.kernel.dk/data/git/qemu.git) hasn't > > > updated in several days so I'm not actually sure it's still there in > > > cvs. > > > > > > Just checked and http://savannah.nongnu.org/svn/?group=qemu isn't > > > there either... > > > > How about git? I'd like to use git bisect. Would there be problems if it > > were possible to commit via more than one interface? > > You mean using nongnu.org's git support? And the cvsserver > emulation, so that CVS people can still access it via CVS? That's an > option, but I do not know if nongnu.org has enabled cvsserver emulation. > > And I'm not a fan of _forcing_ people to switch to another SCM. You can > use git (and even cvsimport yourself, should the public git mirrors lag), > and even svn, as pbrook showed, even if the official upstream stays CVS. Anything but CVS please. SVN is a good option, then people can use their favorite dscm (git-svn, bzr-svn, etc). Right now I can't use qemu because a bug introduced in the last months and with git-bisect I probably would be able to fix it myself. Best regards. -- Felipe Contreras
Re: Git/SVN/CVS? was Re: [Qemu-devel] What does code_copy_enabled do?
Hi, On Sat, 9 Feb 2008, Blue Swirl wrote: > On 2/9/08, Johannes Schindelin <[EMAIL PROTECTED]> wrote: > > > And I'm not a fan of _forcing_ people to switch to another SCM. You > > can use git (and even cvsimport yourself, should the public git > > mirrors lag), and even svn, as pbrook showed, even if the official > > upstream stays CVS. > > I'm not suggesting a forced switch either, that's why I was asking if > it's possible to have R/W access enabled for several SCMs at once. That's tricky. You can mirror, of course, but that is prone to desynchronisation. But as I said, git has a cvs emulator. > I'm also still learning git, can I completely replace CVS access by > using cvsimport and cvsexportcommit locally? I do that in two projects, so yes, you can do that. cvsexportcommit is a little tricky, especially when you do not want to have an extra working directory for CVS. So this is what I do regularly: $ git --git-dir=$(pwd)/.git cvsexportcommit -c -p -u master^ master The "-c" means to really commit when the patch applies, "-p" means to check anally that the patch applies, the "-u" means that it tries to cvs update the files to the correct version first. I need to checkout the "origin" branch for that to work, though (I've been meaning to work on cvsexportcommit, but time is really scarce). Ciao, Dscho
Re: Git/SVN/CVS? was Re: [Qemu-devel] What does code_copy_enabled do?
On 2/9/08, Johannes Schindelin <[EMAIL PROTECTED]> wrote: > Hi, > > On Sat, 9 Feb 2008, Blue Swirl wrote: > > > On 2/8/08, Rob Landley <[EMAIL PROTECTED]> wrote: > > > On Thursday 07 February 2008 21:52:33 Paul Brook wrote: > > > > On Friday 08 February 2008, Rob Landley wrote: > > > > > Grepping through the source code, I can find 3 places where this > > > > > global > > > > > variable is set (it's initialized to a default value of 1, there's > > > > > a "no-code-copy" command line option that sets it to zero, and then it > > > > > shows up in the test suite once). What I can't find is any code ever > > > > > actually checking or using the value put into this variable > > > > > > > > It got ripped out a while back. > > > > > > Any news on the possible cvs->svn migration? I'd submit a cleanup > > > patch to rip out the remaining traces of code_copy_enabled, but the > > > git mirror I follow (git://git.kernel.dk/data/git/qemu.git) hasn't > > > updated in several days so I'm not actually sure it's still there in > > > cvs. > > > > > > Just checked and http://savannah.nongnu.org/svn/?group=qemu isn't > > > there either... > > > > How about git? I'd like to use git bisect. Would there be problems if it > > were possible to commit via more than one interface? > > You mean using nongnu.org's git support? And the cvsserver > emulation, so that CVS people can still access it via CVS? That's an > option, but I do not know if nongnu.org has enabled cvsserver emulation. Something like that. :-) > And I'm not a fan of _forcing_ people to switch to another SCM. You can > use git (and even cvsimport yourself, should the public git mirrors lag), > and even svn, as pbrook showed, even if the official upstream stays CVS. I'm not suggesting a forced switch either, that's why I was asking if it's possible to have R/W access enabled for several SCMs at once. I'm also still learning git, can I completely replace CVS access by using cvsimport and cvsexportcommit locally?
Re: Git/SVN/CVS? was Re: [Qemu-devel] What does code_copy_enabled do?
Hi, On Sat, 9 Feb 2008, Blue Swirl wrote: > On 2/8/08, Rob Landley <[EMAIL PROTECTED]> wrote: > > On Thursday 07 February 2008 21:52:33 Paul Brook wrote: > > > On Friday 08 February 2008, Rob Landley wrote: > > > > Grepping through the source code, I can find 3 places where this global > > > > variable is set (it's initialized to a default value of 1, there's > > > > a "no-code-copy" command line option that sets it to zero, and then it > > > > shows up in the test suite once). What I can't find is any code ever > > > > actually checking or using the value put into this variable > > > > > > It got ripped out a while back. > > > > Any news on the possible cvs->svn migration? I'd submit a cleanup > > patch to rip out the remaining traces of code_copy_enabled, but the > > git mirror I follow (git://git.kernel.dk/data/git/qemu.git) hasn't > > updated in several days so I'm not actually sure it's still there in > > cvs. > > > > Just checked and http://savannah.nongnu.org/svn/?group=qemu isn't > > there either... > > How about git? I'd like to use git bisect. Would there be problems if it > were possible to commit via more than one interface? You mean using nongnu.org's git support? And the cvsserver emulation, so that CVS people can still access it via CVS? That's an option, but I do not know if nongnu.org has enabled cvsserver emulation. And I'm not a fan of _forcing_ people to switch to another SCM. You can use git (and even cvsimport yourself, should the public git mirrors lag), and even svn, as pbrook showed, even if the official upstream stays CVS. Ciao, Dscho
Git/SVN/CVS? was Re: [Qemu-devel] What does code_copy_enabled do?
On 2/8/08, Rob Landley <[EMAIL PROTECTED]> wrote: > On Thursday 07 February 2008 21:52:33 Paul Brook wrote: > > On Friday 08 February 2008, Rob Landley wrote: > > > Grepping through the source code, I can find 3 places where this global > > > variable is set (it's initialized to a default value of 1, there's > > > a "no-code-copy" command line option that sets it to zero, and then it > > > shows up in the test suite once). What I can't find is any code ever > > > actually checking or using the value put into this variable > > > > It got ripped out a while back. > > Any news on the possible cvs->svn migration? I'd submit a cleanup patch to > rip out the remaining traces of code_copy_enabled, but the git mirror I > follow (git://git.kernel.dk/data/git/qemu.git) hasn't updated in several days > so I'm not actually sure it's still there in cvs. > > Just checked and http://savannah.nongnu.org/svn/?group=qemu isn't there > either... How about git? I'd like to use git bisect. Would there be problems if it were possible to commit via more than one interface?
Re: [Qemu-devel] What does code_copy_enabled do?
On Thursday 07 February 2008 21:52:33 Paul Brook wrote: > On Friday 08 February 2008, Rob Landley wrote: > > Grepping through the source code, I can find 3 places where this global > > variable is set (it's initialized to a default value of 1, there's > > a "no-code-copy" command line option that sets it to zero, and then it > > shows up in the test suite once). What I can't find is any code ever > > actually checking or using the value put into this variable > > It got ripped out a while back. Any news on the possible cvs->svn migration? I'd submit a cleanup patch to rip out the remaining traces of code_copy_enabled, but the git mirror I follow (git://git.kernel.dk/data/git/qemu.git) hasn't updated in several days so I'm not actually sure it's still there in cvs. Just checked and http://savannah.nongnu.org/svn/?group=qemu isn't there either... > Paul Rob -- "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson.
Re: [Qemu-devel] What does code_copy_enabled do?
On Friday 08 February 2008, Rob Landley wrote: > Grepping through the source code, I can find 3 places where this global > variable is set (it's initialized to a default value of 1, there's > a "no-code-copy" command line option that sets it to zero, and then it > shows up in the test suite once). What I can't find is any code ever > actually checking or using the value put into this variable It got ripped out a while back. Paul
[Qemu-devel] What does code_copy_enabled do?
Grepping through the source code, I can find 3 places where this global variable is set (it's initialized to a default value of 1, there's a "no-code-copy" command line option that sets it to zero, and then it shows up in the test suite once). What I can't find is any code ever actually checking or using the value put into this variable What's it for? Rob -- "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson.
