On Tue, 2010-01-05 at 10:30 -0600, John Arbash Meinel wrote:
> If you have a purely 'stack' model, and have:
> - - feature2
> - - feature1
> - - upstream
>
> If someone wants just 'feature2' they have to cherrypick or get feature1.
Only if we have merged feature1 stuff into feature2; and its qu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Robert Collins wrote:
> On Tue, 2009-12-15 at 11:15 -0600, John Arbash Meinel wrote:
>>
>> Which (IMO) is something that pushes for having a real DAG in the loom
>> state, rather than just a stack model. As it means you can push *just
>> this thread* i
2010/1/4 Aaron Bentley :
> Barry Warsaw wrote:
>> Correct me if I'm wrong, but reconfigure-pipeline is actually pretty close to
>> what I want, I think. 'bzr reconfigure-pipeline' will create a ./pipes
>> directory in the current working tree, and all new pipes will go there. If
>> this was named
On Tue, 2009-12-15 at 11:15 -0600, John Arbash Meinel wrote:
>
>
> Which (IMO) is something that pushes for having a real DAG in the loom
> state, rather than just a stack model. As it means you can push *just
> this thread* into upstream, and have them merge it, without them
> having
> to merge
Barry Warsaw wrote:
> Correct me if I'm wrong, but reconfigure-pipeline is actually pretty close to
> what I want, I think. 'bzr reconfigure-pipeline' will create a ./pipes
> directory in the current working tree, and all new pipes will go there. If
> this was named .bzr/pipes instead I think tha
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Resurrecting a thread from a few weeks ago...
On Dec 17, 2009, at 01:26 PM, Aaron Bentley wrote:
>Barry Warsaw wrote:
>> I like this because there are
>> no extra directories to worry about, and I can delete the loom
>> directory in one rm-rf and b
> "jam" == John Arbash Meinel writes:
>> The last times I had to merge trunk in these cases was... long
>> ago and mainly had to do with branches left dormant too long.
>>
>> Vincent
>>
jam> Interesting. I have to do it all the time because of NEWS issues...
In th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Vincent Ladeuil wrote:
>> "Aaron" == Aaron Bentley writes:
>
>
>
> Aaron> That is fine with me, but do you have any comments on
> Aaron> the original issue?
>
> Aaron> The original discussion was about "down-thread; pull; up-thread
> "Aaron" == Aaron Bentley writes:
Aaron> That is fine with me, but do you have any comments on
Aaron> the original issue?
Aaron> The original discussion was about "down-thread; pull; up-thread -a"
Aaron> feeling more natural than "pull -d submit:; merge; commit;". It
was
> "jam" == John Arbash Meinel writes:
jam> Vincent Ladeuil wrote:
>> I knew it was going to be a long day :)
>>
>> So I made an mistake in my argumentation. Hurrah ! I was wrong, I
>> learned something new ! That was a good day finally :) Thanks to
>> Aaron and John f
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Barry Warsaw wrote:
> On Dec 18, 2009, at 09:06 AM, John Arbash Meinel wrote:
>
> JAM, you've made some very interesting observations!
>
>> I'll be honest, though. I'm starting to wonder if we really do want to
>> preserve the extra history. I certai
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Barry Warsaw wrote:
> On Dec 17, 2009, at 01:26 PM, Aaron Bentley wrote:
>
>>> Maybe I want to
>>> decide whether the work I had to do to land the code needs extra
>>> review. With a loom, there's no problem finding this. With a
>>> non-loom it's mu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Dec 18, 2009, at 09:06 AM, John Arbash Meinel wrote:
JAM, you've made some very interesting observations!
>I'll be honest, though. I'm starting to wonder if we really do want to
>preserve the extra history. I certainly have made comments that we
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Dec 17, 2009, at 01:26 PM, Aaron Bentley wrote:
>> Maybe I want to
>> decide whether the work I had to do to land the code needs extra
>> review. With a loom, there's no problem finding this. With a
>> non-loom it's much more difficult especial
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Vincent Ladeuil wrote:
> My point was (and is still) that the difference when using a loom
> is that there is a point where you get a better control on how
> the trunk is merged in each thread because the trunk is brought
> "by the bottom", 'up-thread
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Vincent Ladeuil wrote:
> I knew it was going to be a long day :)
>
> So I made an mistake in my argumentation. Hurrah ! I was wrong, I
> learned something new ! That was a good day finally :) Thanks to
> Aaron and John for that.
Sorry to make it feel
I knew it was going to be a long day :)
So I made an mistake in my argumentation. Hurrah ! I was wrong, I
learned something new ! That was a good day finally :) Thanks to
Aaron and John for that.
Why I thought the merge was done in the other direction is still
a bit of a mystery[1]... but irrelev
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Vincent Ladeuil wrote:
>> "jam" == John Arbash Meinel writes:
>
> jam> Nope. You still have to merge it into your top thread and commit
> that.
> jam> So the history in the top thread is the same.
>
> Hmmm, for me, history == graph, the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Barry Warsaw wrote:
> On Dec 16, 2009, at 3:15 PM, Aaron Bentley wrote:
> It's all nice and neat and I can very easily find
> exactly the changes between any two of those tasks.
So, to have a fair comparison with a branch-based approach, let's
conside
> "jam" == John Arbash Meinel writes:
jam> Nope. You still have to merge it into your top thread and commit that.
jam> So the history in the top thread is the same.
Hmmm, for me, history == graph, the graphs are different, so the
histories are different.
trunk -- my changes -- trunk
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Vincent Ladeuil wrote:
>> "Aaron" == Aaron Bentley writes:
> Aaron> In both cases, you are merging the same revision into
> Aaron> the top thread.
>
> No.
In both cases, you are merging from a mirror of trunk into the top
thread. In the
> "Aaron" == Aaron Bentley writes:
Aaron> Vincent Ladeuil wrote:
>>> "jam" == John Arbash Meinel writes:
jam> Actually, those produce the exact same history.
>>
>> No.
>> No. A base thread for trunk were I can pull and feature thread on
>> top is enough.
On Dec 17, 2009, at 8:40 AM, Vincent Ladeuil wrote:
>> "barry" == Barry Warsaw writes:
>
>
>
>barry> loomnon-loom
>barry>
>barry> bzr down-thread rocketfuel bzr merge ../devel
>barry> bzr pull
On Dec 16, 2009, at 4:58 PM, Aaron Bentley wrote:
> There are a lot of similarities. Some more differences are:
> - - automatic storing/restoring of uncommitted changes with switch-pipe.
> - - uncommitted changes in another pipe can be merged.
These are very definitely advantages of pipes.
> I
On Dec 16, 2009, at 4:12 PM, John Arbash Meinel wrote:
> If we are discussing "what is an ideal tool to be building", creating
> something that makes it easier to create a patch file doesn't seem ideal.
Wholeheartedly agree. Patches are dead things, branches are alive.
-Barry
--
ubuntu-distr
On Dec 16, 2009, at 3:15 PM, Aaron Bentley wrote:
>> I do miss this when working on non-loom branches, but of course a 'bzr merge
>> ../devel' is the moral equivalent. It doesn't /feel/ the same though:
>>
>> loomnon-loom
>>
>>
BTW, this thread reminds me of a workflow wart that I'd like to get some advice
on.
Let's say I have a branch or loom or whatever, and I merge in all updates on
the trunk that have happened since I started my branch. I get conflicts. I
have to resolve these conflicts, but doing so may entail
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Vincent Ladeuil wrote:
>> "jam" == John Arbash Meinel writes:
>
> jam> Vincent Ladeuil wrote:
> >>> "barry" == Barry Warsaw writes:
> >>
> >>
> >>
> barry> loomnon-loom
> barry>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Vincent Ladeuil wrote:
>> "jam" == John Arbash Meinel writes:
> jam> Actually, those produce the exact same history.
>
> No.
> No. A base thread for trunk were I can pull and feature thread on
> top is enough.
>
> In one case I *pull* trunk
> "jam" == John Arbash Meinel writes:
jam> Vincent Ladeuil wrote:
>>> "barry" == Barry Warsaw writes:
>>
>>
>>
barry> loomnon-loom
barry>
barry> bzr down-thread rocketfuel bzr mer
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Vincent Ladeuil wrote:
>> "barry" == Barry Warsaw writes:
>
>
>
> barry> loomnon-loom
> barry>
> barry> bzr down-thread rocketfuel bzr merge ../devel
> ba
> "barry" == Barry Warsaw writes:
barry> loomnon-loom
barry>
barry> bzr down-thread rocketfuel bzr merge ../devel
barry> bzr pullbzr commit -m'Merge rocketfuel'
barry> bzr u
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Aaron Bentley wrote:
> John Arbash Meinel wrote:
>> AIUI, being able to share pipelines is not one of your goals.
>
> Pipelines can already be shared with the sync-pipeline command.
They can, but you don't really collaborate on-the-pipeline in the sa
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
John Arbash Meinel wrote:
> AIUI, being able to share pipelines is not one of your goals.
Pipelines can already be shared with the sync-pipeline command.
>> With looms, you get a huge proliferation of threads. I think the only
>> real difference is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
James Westby wrote:
> I realise that there are other advantages, but choosing pipelines just
> because they use real branches for the "threads," wouldn't be a wise
> choice in my eyes. It's not something that can't fit in to the model
> of looms, so we
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Aaron Bentley wrote:
> John Arbash Meinel wrote:
>> Aaron Bentley wrote:
>> I would mention that for packaging, I think you really do want to have
>> 'upstream' as the first thread, which doesn't work with the pipeline
>> model, since a given branch ca
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Barry Warsaw wrote:
> On Dec 16, 2009, at 02:20 PM, Aaron Bentley wrote:
>
>> Barry Warsaw wrote:
>>> When I'm developing bug fix or feature branches, I
>>> always like to have the devel branch as the bottom thread in my loom. Note
>>> too though tha
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Dec 16, 2009, at 02:21 PM, Aaron Bentley wrote:
>Barry Warsaw wrote:
>> We talked in other threads about hiding those pipeline
>> branches so they don't look like siblings in my shared repo directory. That
>> would help a lot.
>
>That's already
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Dec 16, 2009, at 02:20 PM, Aaron Bentley wrote:
>Barry Warsaw wrote:
>> When I'm developing bug fix or feature branches, I
>> always like to have the devel branch as the bottom thread in my loom. Note
>> too though that I want control over when
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Barry Warsaw wrote:
> We talked in other threads about hiding those pipeline
> branches so they don't look like siblings in my shared repo directory. That
> would help a lot.
That's already possible. Is there something holding you back?
Aaron
-
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Barry Warsaw wrote:
> When I'm developing bug fix or feature branches, I
> always like to have the devel branch as the bottom thread in my loom. Note
> too though that I want control over when I update the bottom thread
> independently of when I updat
On Dec 16, 2009, at 01:28 PM, Aaron Bentley wrote:
>With looms, you get a huge proliferation of threads. I think the only
>real difference is that threads tend to be less visible than branches.
For me, that was a big difference and one of the reasons I currently favor
looms over pipelines. We t
On Dec 15, 2009, at 11:15 AM, John Arbash Meinel wrote:
>I would mention that for packaging, I think you really do want to have
>'upstream' as the first thread, which doesn't work with the pipeline
>model, since a given branch can only participate in one pipeline.
Not just for packaging. When I'
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
John Arbash Meinel wrote:
> Aaron Bentley wrote:
> I would mention that for packaging, I think you really do want to have
> 'upstream' as the first thread, which doesn't work with the pipeline
> model, since a given branch can only participate in one p
On Tue Dec 15 16:54:14 + 2009 Aaron Bentley wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> James Westby wrote:
> > There are discussions about whether the "stack" model presented
> > by loom is the best, as it entagles threads that don't necessarily
> > have a dependency. There a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Aaron Bentley wrote:
...
>> Looms are currently available in the bzr-loom plugin, but it
>> is generally agreed that this needs some polish to be really
>> usable.
>
> bzr-pipeline is definitely already usable. I use it daily, and it has
> other fan
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
James Westby wrote:
> There are discussions about whether the "stack" model presented
> by loom is the best, as it entagles threads that don't necessarily
> have a dependency. There are alternative models proposed, including
> a full DAG as implemented
47 matches
Mail list logo