[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] What does code_copy_enabled do?

From: Rob Landley
Subject: Re: [Qemu-devel] What does code_copy_enabled do?
Date: Wed, 13 Feb 2008 02:22:03 -0600
User-agent: KMail/1.9.6 (enterprise 0.20070907.709405)

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 

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


A) Pick a repository as your upstream.  Doesn't matter which, just as long as 
you agree.


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.

"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]