From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: kvm repository unification Date: Tue, 20 Mar 2007 10:58:20 -0500 Message-ID: <4600049C.7090905@codemonkey.ws> References: <45FFCFD7.5000107@qumranet.com> <200703201420.10139.arnd@arndb.de> <45FFE5AB.3030501@qumranet.com> <200703201537.35704.arnd@arndb.de> <45FFF312.2030804@qumranet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org To: Avi Kivity Return-path: In-Reply-To: <45FFF312.2030804-atKUWr5tajBWk0Htik3J/w@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.org Avi Kivity wrote: > Arnd Bergmann wrote: > >> On Tuesday 20 March 2007, Avi Kivity wrote: >> >> >>> How does that work with multiple developers? >>> >>> >> You need a set of well-understood rules if more than one person >> has commit access to the repository. >> >> The most simple rule would be that everyone just adds patches at >> the end of the quilt series. When you submit something upstream, >> you can then still decide to fold multiple patches. >> >> > > That essentially mimics the subversion workflow, where a commit is > equivalent to appending a patch. > I find using a patch queue useful though for submitting things upstream. A good example is our QEMU changes. It's a real pain to break apart the SVN history into individual patches. I tend to keep the patches in revision control too. In the paravirt_ops queue, they keep a file that contains the changeset ID of whatever the patches are based off of. That tends to help with respect to going backwards in history. >> As an extension, it is possible to allow changing a previous patch >> by replacing it with a forked one. E.g. kvm-add-foo.patch can >> get replaced by kvm-add-foo-2.patch, when that contains an improved >> version. >> >> > > Ewww, diffs of patches! Better to have separate 'add cleanup patch' and > 'fold-with-no-change' steps. > > >> I've never tried the cherry pick approach, since my team for historic >> reasons still uses CVS, which doesn't have changesets. If it works well >> for you, I guess you shouldn't change. >> >> > > I'm mostly comfortable by now with git, but there are others here who > are sweating blood over it, so I'm interested in alternatives. > Mercurial is *much* friendlier than git. Linus' tree is available via mercurial too. It should be pretty easy to maintain the KVM changes as a patch queue against Linus' tree. We could have Makefile magic too to clone a kernel/qemu tree and apply the patch queue that a top level "make" still did the right thing. Regards, Anthony Liguori ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV