On Tue, 05 Oct 2010 09:16:36 -0500, John Arbash Meinel
wrote:
> I've been thinking about it, and I'm pretty confident that what you are
> trying to do is inherently "criss-cross". Specifically consider a
> semi-ideal case:
>
> upstream
>
> A release 2.0
> |
> B release 2.1
> |
>
On Tue, 5 Oct 2010 10:50:08 -0400, Barry Warsaw wrote:
> Won't all the patches Debian (or Ubuntu) adds be in patch system files living
> in debian/? Of course, the looms<->patchsystem idea kind of blurs that, but
> ultimately the packaging directory should fully contain any downstream changes
> U
On Mon, 04 Oct 2010 19:20:32 -0500, John Arbash Meinel
wrote:
> So you preserve the content of exactly D or E, you just generate a new
> node in the graph to supersede the other one, correct?
Yes.
> Say D is the 'winner', then you end up with a patch that reverts
> everything in E.
Yes, except
On Tue, 2010-10-05 at 09:58 -0500, John Arbash Meinel wrote:
> On 10/5/2010 9:50 AM, Barry Warsaw wrote:
> > On Oct 05, 2010, at 09:37 AM, John Arbash Meinel wrote:
> >
> >> Now, I would imagine that the *interesting* merges are not clean like
> >> this. Why would you really care about merging if
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/5/2010 9:50 AM, Barry Warsaw wrote:
> On Oct 05, 2010, at 09:37 AM, John Arbash Meinel wrote:
>
>> Now, I would imagine that the *interesting* merges are not clean like
>> this. Why would you really care about merging if debian isn't adding
>> p
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Oct 05, 2010, at 09:37 AM, John Arbash Meinel wrote:
>Now, I would imagine that the *interesting* merges are not clean like
>this. Why would you really care about merging if debian isn't adding
>patches to the upstream code? (Other than procedura
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/5/2010 9:27 AM, Barry Warsaw wrote:
> On Oct 05, 2010, at 09:16 AM, John Arbash Meinel wrote:
>
>> I've been thinking about it, and I'm pretty confident that what you are
>> trying to do is inherently "criss-cross". Specifically consider a
>> se
On Oct 05, 2010, at 09:16 AM, John Arbash Meinel wrote:
>I've been thinking about it, and I'm pretty confident that what you are
>trying to do is inherently "criss-cross". Specifically consider a
>semi-ideal case:
This is all fascinating, and while I have nothing constructive to add, I
wonder: do
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/4/2010 7:20 PM, John Arbash Meinel wrote:
>
> ...
>> We create a new revision with D & E as parents, and the contents of the
>> later of the two (defined in terms of upstream version numbers). So, no,
>> there is no possibility of conflicts at t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
...
> We create a new revision with D & E as parents, and the contents of the
> later of the two (defined in terms of upstream version numbers). So, no,
> there is no possibility of conflicts at this stage.
So you preserve the content of exactly D or
On Mon, 04 Oct 2010 17:01:01 -0500, John Arbash Meinel
wrote:
> On 9/29/2010 11:23 PM, James Westby wrote:
> > What merge package does is first merge the two upstream revisions
> > together, taking the tree from whichever has the highest version number.
> >
> > ---B---F
> > / / /
> > / /
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 9/29/2010 11:23 PM, James Westby wrote:
...
> Here's why: (apologies to anyone using screen readers or variable width
> fonts)
>
> ---B---F
> / / /
> / / .-D
> \ A-=
> \`-E
> \ \
>C--G
>
> (Time passes as you go right)
Hi,
I'd like someone to check my thinking before I make a change, as I don't
want to introduce data loss or something.
First, some background.
We have a merge-package command, as a simple bzr merge doesn't cut it on
occaision.
Here's why: (apologies to anyone using screen readers or variable wi
13 matches
Mail list logo
