incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From eric b <>
Subject Re: [Code] strategy for "child works spaces"
Date Sun, 20 Nov 2011 11:52:59 GMT
Hi Christian,

Le 20 nov. 11 à 12:22, Christian Lohmaier a écrit :

> Hi Eric, *,
> On Sun, Nov 20, 2011 at 10:12 AM, eric b <> wrote:
>> Le 19 nov. 11 à 22:55, Mathias Bauer a écrit :
>>> Am 19.11.2011 15:22, schrieb Pedro Giffuni:
>>> I still prefer the conversion of a cws in single diffs, each one
>>> representing a single commit.
>> Me too.  That's the most efficient way to integrate a cws.
> No, it is not.

I meant in Apache current source code we can checkout  
using svn.

> A cws can be long lived, could have underwent multiple rebases with  
> the current tree, so there are lots of commits that refer
> to a old version of the code and thus won't apply anymore.

My proposal was to adapt the full cws, who will very probably not  
apply to the sources directly.

> Unless you want to do lots of detecitve work and redo all the  
> merging work that the author of the cws did do already over the  
> course of
> time, trying to apply a cws by its individual commits is a waste of  
> time, not to mention that it is

Let's give an example : I download a full diff of one cws. patch -- 
dry-run -px  < the_diff

The result will give some fuzz + some failed. The idea is to  
regenerate a new full diff, able to apply on the tree, as a set of  

> The version to apply a cws to a different version-control system is  
> to create a diff agains the current milestone the cws is based on  
> and try to apply that one. (feel free to create a diff for each  
> module).

Good catch : the atomicity of the diffs is important, and yes, create  
one diff per modules seems more accurate. In parallel, we should  
maintain a log for any cws we integrated this way, of course.

> This will give way less conflicts and is much faster. You loose  
> history,

Yes, we loose history and I'm not satisfied with that. Just wondering  
whether we could keep the old full diff on the repo + add information  
inside the new diff ?

>  that was your decision when converting the repo to begin with.

I'm not sure to understand. You meant a common decision ?



Projet OOo4Kids :
L'association EducOOo :
Blog :

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message