Re: kvm repository unification

[Anthony Liguori <anthony-rdkfGonbjUSkNkDKm+mE6A@public.gmane.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