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=
Message-ID: <address@hidden>
Date: Wed, 13 Feb 2008 11:18:29 +0200
From: "Felipe Contreras" <address@hidden>
To: "Rob Landley" <address@hidden>
Subject: [***SPAM*** Score/Req: 07.60/07.00] Re: [Qemu-devel] What does code_copy_enabled do?
In-Reply-To: <address@hidden>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <address@hidden>
	<address@hidden>
	<address@hidden>
	<address@hidden>
Cc: Ian Jackson <address@hidden>, address@hidden,
	Blue Swirl <address@hidden>, Paul Brook <address@hidden>
Precedence: list
Reply-To: address@hidden
Sender: address@hidden
Errors-To: address@hidden

On Feb 13, 2008 10:22 AM, Rob Landley <address@hidden> 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