-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* into
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 quite
-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 be
2010/1/4 Aaron Bentley aa...@canonical.com:
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
-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
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 much more
jam == John Arbash Meinel j...@arbash-meinel.com 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
Aaron == Aaron Bentley aa...@canonical.com writes:
snip/
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;
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Vincent Ladeuil wrote:
Aaron == Aaron Bentley aa...@canonical.com writes:
snip/
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;
barry == Barry Warsaw ba...@canonical.com writes:
snip/
barry loomnon-loom
barry
barry bzr down-thread rocketfuel bzr merge ../devel
barry bzr pullbzr commit -m'Merge rocketfuel'
jam == John Arbash Meinel j...@arbash-meinel.com writes:
jam Vincent Ladeuil wrote:
barry == Barry Warsaw ba...@canonical.com writes:
snip/
barry loomnon-loom
barry
barry bzr down-thread
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
Aaron == Aaron Bentley aa...@canonical.com writes:
Aaron Vincent Ladeuil wrote:
jam == John Arbash Meinel j...@arbash-meinel.com writes:
jam Actually, those produce the exact same history.
No.
No. A base thread for trunk were I can pull and feature thread on
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Vincent Ladeuil wrote:
Aaron == Aaron Bentley aa...@canonical.com 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.
jam == John Arbash Meinel j...@arbash-meinel.com 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
-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
consider
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Vincent Ladeuil wrote:
jam == John Arbash Meinel j...@arbash-meinel.com 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 ==
-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
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'm
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
-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 can
-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 same
22 matches
Mail list logo
