Re: Recipes vs. Looms vs. pipelines
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 possible to skip doing that while preserving a stack description - remember that each revision has dag info, so we don't need a dag at the list of branches level. > The changes for loom itself, are stuff like 'up-thread' from feature1 => > feature2 is just a 'switch'. But up-thread from feature2 => integration > (or feature1) requires a merge from both feature1 and feature2 (probably > committing inbetween.) I think I filed a bug, but I plan to reduce the noop commits massively here. -Rob signature.asc Description: This is a digitally signed message part -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Recipes vs. Looms vs. pipelines
-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 upstream, and have them merge it, without them >> having >> to merge all of your other changes. Otherwise the loom is just there >> to >> help you develop the patch. And then you throw away all the history >> once >> the patch gets applied to upstream. > > I'm not quite sure what you mean by this. The relationship between > threads being DAG | sequence won't affect what merges are needed. > > -Rob If you have a purely 'stack' model, and have: - - feature2 - - feature1 - - upstream If someone wants just 'feature2' they have to cherrypick or get feature1. If you had a DAG with: - - integration => feature1, feature2 - - feature2 => upstream - - feature1 => upstream - - upstream Then someone can just 'bzr merge feature2' and get only those changes. The changes for loom itself, are stuff like 'up-thread' from feature1 => feature2 is just a 'switch'. But up-thread from feature2 => integration (or feature1) requires a merge from both feature1 and feature2 (probably committing inbetween.) John =:-> -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAktDaS0ACgkQJdeBCYSNAAO0pQCcD9Q8vzI22axn1ZPC75rcP/Cy dfYAn0jKCN9ceXc2zXuMw25F3sl1xTAj =HtNK -END PGP SIGNATURE- -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Recipes vs. Looms vs. pipelines
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 .bzr/pipes instead I think that would be perfect. > > That is right. If you find any problems with this, please report them > as bugs. > >> I did a quick and dirty hack which seems to DTRT. > > I saw that, and I'm 95% certain I'll land it as-is. It's possible I'll > add an option to restore the previous behaviour. My original motivation > for using a location outside the .bzr was to avoid too much "magic". I > was on a "pipes are just branches" kick. > OMG yes please. I've nuked my pipes quite a few times by running bzr clean-tree --ignored because upstream distclean targets were broken. -- With best regards Dmitrijs Ledkovs (for short Dima), Ледков Дмитрий Юрьевич () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Recipes vs. Looms vs. pipelines
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 all of your other changes. Otherwise the loom is just there > to > help you develop the patch. And then you throw away all the history > once > the patch gets applied to upstream. I'm not quite sure what you mean by this. The relationship between threads being DAG | sequence won't affect what merges are needed. -Rob signature.asc Description: This is a digitally signed message part -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Recipes vs. Looms vs. pipelines
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 that would be perfect. That is right. If you find any problems with this, please report them as bugs. > I did a quick and dirty hack which seems to DTRT. I saw that, and I'm 95% certain I'll land it as-is. It's possible I'll add an option to restore the previous behaviour. My original motivation for using a location outside the .bzr was to avoid too much "magic". I was on a "pipes are just branches" kick. I should mention that, as a launchpad developer, you probably have a bunch of configuration in ~/.bazaar/locations.conf that uses the "appendpath" configuration policy to set your public, submit, pull and push locations. Have a look with "bzr info" to see if any of those locations have gone haywire. (https://bugs.launchpad.net/bzr-pipeline/+bug/416962 is related to the appendpath issue.) > Hacking reconfigure to set up .bzr/pipes when run in a lightweight checkout > might be a good idea too, but I don't think I'll tackle that one. I think that most of the time, if there's a lightweight checkout, the user has already decided to put their branches somewhere else. So I think there may not be any demand for this. Aaron -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Recipes vs. Looms vs. pipelines
-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 completely done with it. > >This is actually co-location of trees with their branches. You can >accomplish this with lightweight checkouts by putting the branch inside >the .bzr directory of the branch. > >$ bzr init foo >Created a standalone tree (format: 2a) > >$ bzr checkout foo bar >$ mkdir bar/.bzr/branches >$ mv foo bar/.bzr/branches/ >$ cd bar >$ bzr switch --force .bzr/branches/foo >Tree is up to date at revision 0. >Switched to branch: /home/abentley/sandbox/bar/.bzr/branches/foo/ > >Obviously, this is more steps than it should be, but it would be easy to >turn into a reconfigure operation. 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 that would be perfect. I did a quick and dirty hack which seems to DTRT. https://bugs.edge.launchpad.net/bzr-pipeline/+bug/503006 https://code.edge.launchpad.net/~barry/bzr-pipeline/dotfile It does mean that instead of doing a lightweight checkout to start with, I would use a straight up 'bzr branch foo bar' then reconfigure. I could live with that. Maybe a better name for that would be 'init-pipes'. I'll just add that as the sixth essential pipeline alias. :) Hacking reconfigure to set up .bzr/pipes when run in a lightweight checkout might be a good idea too, but I don't think I'll tackle that one. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iQIcBAEBCAAGBQJLQhQKAAoJEBJutWOnSwa/w88QALxj61jvNuYI18lwRh86uked u/cSpGWFd7cd1lffmw8loFim8tfjUUBLHglMmmlyrIsl/6RCPGk7OhF6vymWWpSZ M1nQEJeUTK4XVzuwPynD5yq0YTNsH45YbNo+WZmAMghC9jFwFq4LM8vhVWf+uULa hwcCYwBYGQYncUTah9kllyjqpATX7Xk4H6tUy3H7EbTzFHoT6ma0WS4WOy62OPrr cqT4qBj0gFeWpcxq12T0Vhgzgvg0vvyh93YrM+A4CKB2jr754GhR+5f0H7oUp9ud 67w+RDzIQkyyWKWbHpyxDWe+VZY3O2jJm4/q431jiWKowEqCjQMxnxbBpq8xJVwE 3jgm0uEK4Vty+aBvDJKZPHOHJqvf1vw+nulps2qnzEzEWkjvKYL1gb2cJ+zcIPaV 5SsmuCsRG7x1UWUBDEbvNW8KuYMeCDqPVLEM3FssJuhu19FyF06FTG/QMDLM49GE JfwCXIvY1Dbujf3j7SHDMGCkOs3AVaBd0mx4UvLXtairklWpq0UPDWIo4ApxeOSm l2TDhpjLl4HbcZSAtcVeI0ezpd/VWK543BcfHs/zDYtgoY6vJQSCog1yuz7+Nf5M S/jqS1kjn1J+T2VApbuXxCR3FuftBHr5VEazC1LfIGVzSL/oyrYxsp8QChh2OnvI SV7HWknL1w2PBD5JSMcQ =Hz3A -END PGP SIGNATURE- -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Recipes vs. Looms vs. pipelines
> "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 the integration branch, me too, that's why I tend to *not* merge trunk until the pqm submission and that works most of the time. Vincent -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Recipes vs. Looms vs. pipelines
-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 -a" > Aaron> feeling more natural than "pull -d submit:; merge; commit;". It > wasn't > Aaron> about the advantages of stacks when you have multiple lines of > Aaron> development, it was about the loom workflow feeling more natural > even > Aaron> when you only had one line of development. > > That's not how I understood it, but I've been wrong before :-D > > So yes, I find the loom workflow feeling more natural. > > But that's not really relevant (to me and IME) when there is a > single line of dev. That's mainly because in that case I > generally don't merge trunk until the submission. And in that > case I do the merge and resolve the conflicts in my integration > branch. > > 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 > Interesting. I have to do it all the time because of NEWS issues... John =:-> -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAksrvIQACgkQJdeBCYSNAAN5zgCfSJnwo5NZCI2U34igOI6917x6 jXAAoJOEoxXf7Z465dGjQdEbCJRqXiYG =wUVX -END PGP SIGNATURE- -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Recipes vs. Looms vs. pipelines
> "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 wasn't Aaron> about the advantages of stacks when you have multiple lines of Aaron> development, it was about the loom workflow feeling more natural even Aaron> when you only had one line of development. That's not how I understood it, but I've been wrong before :-D So yes, I find the loom workflow feeling more natural. But that's not really relevant (to me and IME) when there is a single line of dev. That's mainly because in that case I generally don't merge trunk until the submission. And in that case I do the merge and resolve the conflicts in my integration branch. 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 -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Recipes vs. Looms vs. pipelines
> "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 for that.
jam> Sorry to make it feel like it was an attack. I honestly
jam> did want to understand why you felt it was different.
Well, no worries. Replying to the *other* part of the mail would
have helped though.
This reply is full of gems.
>>
>> Why I thought the merge was done in the other direction is still
>> a bit of a mystery[1]... but irrelevant to the discussion.
jam> ^- I think there is a missing footnote here :)
Hehe, damn, I left that, never left any typo for jam :0D
Ok, so the I thought a bit about it and I think it was because in
my head I see the branch I'm working on at the left and
everything I'm merging into it on the right.
Then I put the loom on the left... or something like that and I
get confused :) Nothing relevant to the discussion.
But your 'bzr qlog trunk vila jam' is quite close, except the
columns are reversed in my head which qlog can't produce.
>>
>> So what I meant is shown below (you can paste the following in
>> bzrlib/tests/test_script.py and run
>> bzr selftest -s bt.test_script.TestGraphs).
jam> Easier to just cut off the $ and run in a real shell, but both work.
I take that as a compliment :D
The side point was to show that it was easily turned into a test,
so anybody feel welcome to write such tests :)
The main advantage is that you don't need to cleanup or take
cleanup into account like you have when when writing it as a
shell script.
And... it's easy to organize/run (selftest -s)/commit (thanks
bzr), etc (including dogfooding is good).
>>
>> Gee, 13 and 14 commands respectively for the simplest example :-(
>>
>> 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 --auto' stops in case of conflicts
>> for a good reason.
jam> So that is true, but it would be identical if you used 2
jam> feature branches. And in fact, if I was trying to
jam> separate features like that, *I* would try to do it as:
Indeed, but using a loom is simpler.
jam> bzr init trunk
jam> bzr commit -m "trunk" --unchanged trunk
jam> bzr branch trunk vila
jam> bzr branch trunk jam
jam> bzr commit -m "vila1" vila
jam> bzr commit -m "jam1" jam --unchanged
jam> bzr commit -m "trunk2" --unchanged trunk
..and having that as a test makes it trivial to fix:
def test_with_feature_branches(self):
self.run_script("""
$ bzr init trunk
$ bzr commit -m "trunk" --unchanged trunk
$ bzr branch trunk vila
$ bzr branch trunk jam
$ cd vila
$ bzr commit -m "vila1" --unchanged
$ cd ../jam
$ bzr commit -m "jam1" --unchanged
$ cd ../trunk
$ bzr commit -m "trunk2" --unchanged
$ bzr qlog jam vila trunk
$ bzr qlog trunk vila jam
""")
jam> bzr qlog trunk vila jam
jam> # Note that this is my argument for a DAG based loom/pipeline. As at
jam> # this point, you can decide your dependencies, and do
More and more people are agreeing here. It was my first idea as
an ideal tool then I tried to mix looms with pipelines at the
top, then wondered if hammer-merging can be enough and I'm back
to either loom or loom/pipelines...
But I think mentioning the various ways they are used and the
associated rough edges is a great way to progress.
jam> cd vila
jam> bzr merge ../trunk; bzr commit -m "merge trunk to vila"
jam> cd ../jam
jam> # either
jam> bzr merge ../trunk; bzr commit -m "merge trunk to jam"
jam> # or
jam> bzr merge ../vila; bzr commit -m "merge vila(+trunk) to jam"
jam> You probably want to visualize this with:
jam> bzr qlog jam vila trunk
jam> Though
jam> bzr qlog trunk vila jam
jam> Looks interesting.
Definitely and very close to my mysterious weird mental
representation.
jam> Of course, separate branches play nicer with 'qlog'
jam> today, but I don't see any reason why qlog couldn't show
jam> the same graph and labels for threads that it shows for
jam> branches.
jam> Anyway, it depends on how much the 'vila' features are
jam> necessary for the 'jam' features, vs how independent
jam> they are.
Yes. And things can get even more complicated. So without a good
UI and I fear a GUI is required, there are big usability issues
here.
>>
>> The graphs are different because more information is preserved in
>> the loom case, that's basically the same argumentation about
>> rebase or not rebase, these additional commits may seem spurious
>> but that's a different debate.
>>
>> Putting
Re: Recipes vs. Looms vs. pipelines
-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 certainly have made comments that we don't >> want to write a system that makes a glorified "patch". Though honestly, >> what you really care about landing in upstream is a "change". In loom >> terminology, you really do only care about "bzr diff -rthread:" as that >> is what is going to be reviewed upstream. > > I think that's absolutely right. Note though, that it's not until I'm ready > to publish my work that I'd be ready to collapse things down. IOW, while the > work is still in progress, I do care about each revision. When I'm ready to > push though, I think those individual revisions are much less interesting. Of > course, this "collapsing" might happen more than once during the lifetime of a > branch (e.g. hey-can-you-help-me-with-this, ready-for-review, > i've-responded-to-your-review, ready-to-land). So we do this in the bzr project by using the "left parent is more important" model. Specifically, the collapse occurs because: "bzr merge; bzr commit; bzr log -n1" will only show you the merge commits, which have effectively collapsed the changes into individual bytes. And interestingly, this is sort of what you have with loom if you re-ordered the parents. (If up-thread --auto did what vila originally thought it did.) I think if we did that parent swapping on each up-thread, it would probably mess up the development flow. However, you could have a fairly simple command that could do that. John =:-> -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAksro+8ACgkQJdeBCYSNAAN+/gCgtrOqVsIFm+xs1tBA0pqbZx99 SU8AoLIzmhWQUCGSD1C2IOfSJ7Z2iK6P =8Hcd -END PGP SIGNATURE- -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Recipes vs. Looms vs. pipelines
-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 difficult especially if you've got several >>> trunk merges interspersed. >> Sure, I can see the virtue of a stack-based approach if you want to view >> the work separately. But this doesn't help me understand why you would >> want trunk as the base thread. > > What happens if I update my trunk? Nothing bad, IME. > In the loom-based approach, my bottom > thread won't be updated until I explicitly take that step. In the branch > based approach, all my branches will "see" the update. "See" in what sense? If you mean that they will diff against the wrong version, they won't if you use -r submit: or -r ancestor: >>> Updating the bottom thread and up-threading --auto falls into this. >>> It's usually a trivial, inconsequential afterthought. Most changes >>> on trunk don't affect my work, so I don't care about them. I'm >>> merging trunk to be diligent. The fact that I can mentally segregate >>> that to the bottom thread helps me ignore it completely in the common >>> case, even if the end result is the same. >> I don't see how this lets you mentally segregate it to the bottom >> thread. up-thread --auto affects all threads. > > Right, but it's the difference between thinking about it like: "oh, I'm just > tracking trunk changes" to "I'm weaving in the trunk changes with my current > work". I dunno, maybe I need to change my mental model, but to me there's a > very distinct difference. I think of "pull" as the "tracking" command and "merge" as the "weaving into my work" command. It almost sounds like you're thinking of the pull into trunk as "merging trunk". Is that accurate? >> This is actually co-location of trees with their branches. You can >> accomplish this with lightweight checkouts by putting the branch inside >> the .bzr directory of the branch. > >> $ bzr init foo >> Created a standalone tree (format: 2a) > >> $ bzr checkout foo bar >> $ mkdir bar/.bzr/branches >> $ mv foo bar/.bzr/branches/ >> $ cd bar >> $ bzr switch --force .bzr/branches/foo >> Tree is up to date at revision 0. >> Switched to branch: /home/abentley/sandbox/bar/.bzr/branches/foo/ > > Thanks, that helps a lot. I will definitely give this a shot for the next > branch I'm working on. Cool. Note that the checkout command should actually be "bzr checkout - --lightweight bar". (I have "checkout" aliased to "checkout - --lightweight --hardlink".) Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksroukACgkQ0F+nu1YWqI3hVgCfTH+c6mPS5956vzj4OdRqfGX2 788An1cXGPmGyYqx0MuYAPi9FWoDZIaR =idZj -END PGP SIGNATURE- -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Recipes vs. Looms vs. pipelines
-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 don't >want to write a system that makes a glorified "patch". Though honestly, >what you really care about landing in upstream is a "change". In loom >terminology, you really do only care about "bzr diff -rthread:" as that >is what is going to be reviewed upstream. I think that's absolutely right. Note though, that it's not until I'm ready to publish my work that I'd be ready to collapse things down. IOW, while the work is still in progress, I do care about each revision. When I'm ready to push though, I think those individual revisions are much less interesting. Of course, this "collapsing" might happen more than once during the lifetime of a branch (e.g. hey-can-you-help-me-with-this, ready-for-review, i've-responded-to-your-review, ready-to-land). >I am starting to think that history should be "immutable" but with the >possibility of annotating it. Consider a commit: > "Remove foo and bar making it 10x faster." >That you could later annotate with: > "Note: This was a *bad* idea, as it broke OS X and Windows and..." +1 >It would be nice to have that note at least referenced when looking at >the original commit. > >As for preserving everything... There is an argument for keeping the >signal to noise ratio high enough that things stay useful. Yep, although one person's signal is another person's noise. :) - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iQIcBAEBCAAGBQJLK1aLAAoJEBJutWOnSwa/XHQP/2qaP2vXAOzTrIn6fHROGY2m 50e060p4NWICG5tAJmIH5hmD1oP/PtCtzmLMJNGKlZ/xovk8v5ej9Wo8KtmRoqfC pTApaaVY4aYGNorKLxgX78bHReaGXuEiHrl1R/+aFelyvknl2fv5u1AhCzDWJCJn a+o2+wDYLCU4ugYCQ6vxM2FY9AElZ2Mkt/IPXjxgZhMuNcbMDm+70eFLZS+xzhfX Kx1tvHJnNfwP5JNwssyavCoy7wsAqfr+RFYVg9i6gZJCQAyl3cp8UMf77lCmCqjZ jz8cb2eKdVM9BlNLGTunqruhtwf5jhLXA3Zl/PQ9ZXadzC8WpthVOUYH3eW7knDJ Q+d1m1ToyXitTYwPUhuiBfwRDzeOonqNVBg6hVnREDk+r2TWZIQ7G7koO+Evhhro WobkZ4II9J1JF9in6/7ArhTmmGM+MyxEpnDKxCOnd3c+3WYxuIqqzgZdJc5DJlc7 /GwluYqQAlQwiFIl5WCGy4DuYFz4RySSHreFULzROmKWucrXUet+58w43qaE1F+A /K1pvGr7KDxin8YXQpLjG0TCRomLOHLqfr0XIq6q/hfJjVQs+QVF8T5E+Lsy9Xw1 V4b9TLdp/qRPpyo3UeRgWvH2GvQzj3NeRCtxmcr0OUR0SCAEUADxXCXAf49nKBzo jYGLAClvuQYEEWG8Mz7u =Bh0A -END PGP SIGNATURE- -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Recipes vs. Looms vs. pipelines
-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 especially if you've got several >> trunk merges interspersed. > >Sure, I can see the virtue of a stack-based approach if you want to view >the work separately. But this doesn't help me understand why you would >want trunk as the base thread. What happens if I update my trunk? In the loom-based approach, my bottom thread won't be updated until I explicitly take that step. In the branch based approach, all my branches will "see" the update. >I have thought about implementing a diff that ignores changes introduced >by merges. It's just a matter of tuits. That would definitely help. >> Updating the bottom thread and up-threading --auto falls into this. >> It's usually a trivial, inconsequential afterthought. Most changes >> on trunk don't affect my work, so I don't care about them. I'm >> merging trunk to be diligent. The fact that I can mentally segregate >> that to the bottom thread helps me ignore it completely in the common >> case, even if the end result is the same. > >I don't see how this lets you mentally segregate it to the bottom >thread. up-thread --auto affects all threads. Right, but it's the difference between thinking about it like: "oh, I'm just tracking trunk changes" to "I'm weaving in the trunk changes with my current work". I dunno, maybe I need to change my mental model, but to me there's a very distinct difference. >This is actually co-location of trees with their branches. You can >accomplish this with lightweight checkouts by putting the branch inside >the .bzr directory of the branch. > >$ bzr init foo >Created a standalone tree (format: 2a) > >$ bzr checkout foo bar >$ mkdir bar/.bzr/branches >$ mv foo bar/.bzr/branches/ >$ cd bar >$ bzr switch --force .bzr/branches/foo >Tree is up to date at revision 0. >Switched to branch: /home/abentley/sandbox/bar/.bzr/branches/foo/ Thanks, that helps a lot. I will definitely give this a shot for the next branch I'm working on. >Obviously, this is more steps than it should be, but it would be easy to >turn into a reconfigure operation. +1 >> I should note thought that there's a wart in looms related to this: >> export-loom. If I have to share my loom threads with others (e.g. a >> merge proposal), I have to export it into separate branches. > >You can also use import-loom to convert it to a pipeline, which will >preserve ordering information, so it can be used by lp-submit. Neat! - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iQIcBAEBCAAGBQJLK1Q5AAoJEBJutWOnSwa/Q74QAIr197c6mo81Y/BkO9V8F/ZK VRGxJdt2zmWa2TuZvytYtyxzw7lprxE7UqaOdrWLjrcNRtMsnHLXfVs6in+25mar zPhk214fiw0TGs6nvWq3m24SNB2WewgcxuXUe02t9jea899J+ObbllcFsHGuLOQF PAr1hWK9z5osw9uJFcO0YfeedQSQ4oX/HZpA2HlljVFzym3W2Ai5rUxZintV283g lpRJiRJbj5GA6Y7kuuWQF6l2Rv/bRrgF4YKg/GGi+CdG475sappCYnPJMKbYuOil QxXC0poT8k1enIwTFikaV04xSyg7CJF3vBZeQBjZ9ClXeADhzz02ZQ41EpB39UdW 4khzinw9TiZEf459w6LDR6iiqUh/lXSVdeA0h3Y00lRSzKsd1iUCiosMPKwuFpcA ZFuKIVlxCIzosGFrnfM8RT1JF6hFE+h6rga86aGs92JOUBUBJ9U5KtHZo5CPxuUx tiRAf/mNcm/Iozu1Km57xxfy9hDAHGK7QF/Mh7dCk3aM/MP3zeCdR/qtVlamfX3d me+o+iIUq4X1TgLGVlf9NcQTRAJmhjYYPYbaYFXYxu8PznJU5bQbVz82K+Ip8kGe F1mfDmP6cf38uMvkAc6eAwKQHfpxTyPl+ururJ5jWA/L8+YHUk3rMluzRrkbk7eG VggG9AkGT5lFsixDNlIv =CsJg -END PGP SIGNATURE- -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Recipes vs. Looms vs. pipelines
-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 --auto' stops in case of conflicts > for a good reason. I understand and agree. > Putting that back in the udd context means that you get a chance > to resolve the conflicts from upstream (there shouldn't be any > since we do a pull and we can do that because we preserved the > starting point) before resolving the conflicts from each patch, > the conflicts from debian and finally the conflicts from ubuntu. That is fine with me, but do you have any comments on the original issue? The original discussion was about "down-thread; pull; up-thread -a" feeling more natural than "pull -d submit:; merge; commit;". It wasn't about the advantages of stacks when you have multiple lines of development, it was about the loom workflow feeling more natural even when you only had one line of development. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksrnckACgkQ0F+nu1YWqI0w/gCfSF7+/2l/ov+k/YbHkOfmcOFL u8oAnAiWnxLELt4x6yWQHa+N7oPuIWwO =XuGF -END PGP SIGNATURE- -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Recipes vs. Looms vs. pipelines
-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 like it was an attack. I honestly did want to understand why you felt it was different. > > Why I thought the merge was done in the other direction is still > a bit of a mystery[1]... but irrelevant to the discussion. ^- I think there is a missing footnote here :) > > So what I meant is shown below (you can paste the following in > bzrlib/tests/test_script.py and run > bzr selftest -s bt.test_script.TestGraphs). Easier to just cut off the $ and run in a real shell, but both work. > > More than two threads needs to be involved of course. > ... > > Gee, 13 and 14 commands respectively for the simplest example :-( > > 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 --auto' stops in case of conflicts > for a good reason. So that is true, but it would be identical if you used 2 feature branches. And in fact, if I was trying to separate features like that, *I* would try to do it as: bzr init trunk bzr commit -m "trunk" --unchanged trunk bzr branch trunk vila bzr branch trunk jam bzr commit -m "vila1" vila bzr commit -m "jam1" jam --unchanged bzr commit -m "trunk2" --unchanged trunk bzr qlog trunk vila jam # Note that this is my argument for a DAG based loom/pipeline. As at # this point, you can decide your dependencies, and do cd vila bzr merge ../trunk; bzr commit -m "merge trunk to vila" cd ../jam # either bzr merge ../trunk; bzr commit -m "merge trunk to jam" # or bzr merge ../vila; bzr commit -m "merge vila(+trunk) to jam" You probably want to visualize this with: bzr qlog jam vila trunk Though bzr qlog trunk vila jam Looks interesting. Of course, separate branches play nicer with 'qlog' today, but I don't see any reason why qlog couldn't show the same graph and labels for threads that it shows for branches. Anyway, it depends on how much the 'vila' features are necessary for the 'jam' features, vs how independent they are. > > The graphs are different because more information is preserved in > the loom case, that's basically the same argumentation about > rebase or not rebase, these additional commits may seem spurious > but that's a different debate. > > Putting that back in the udd context means that you get a chance > to resolve the conflicts from upstream (there shouldn't be any > since we do a pull and we can do that because we preserved the > starting point) before resolving the conflicts from each patch, > the conflicts from debian and finally the conflicts from ubuntu. > Sure. Though it is the same if you use pipelines or split your commits into feature branches manually. 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 don't want to write a system that makes a glorified "patch". Though honestly, what you really care about landing in upstream is a "change". In loom terminology, you really do only care about "bzr diff -rthread:" as that is what is going to be reviewed upstream. I guess the argument is for improved annotations. Though if you were diligent to create threads for each logical step, then you would have them. *And* they wouldn't be cluttered with "I'm done for tonight, restarting tomorrow". I used to think that all history should be immutable and preserved. However, I save all my emails, and usually I can't find what I want because I have to sift through 1000s of bogus ones. (Yes this is also an argument for improved search...) I am starting to think that history should be "immutable" but with the possibility of annotating it. Consider a commit: "Remove foo and bar making it 10x faster." That you could later annotate with: "Note: This was a *bad* idea, as it broke OS X and Windows and..." It would be nice to have that note at least referenced when looking at the original commit. As for preserving everything... There is an argument for keeping the signal to noise ratio high enough that things stay useful. Anyway, things have digressed far from the original comments. >Vincent > > P.S.: I don't attach the 40kB screenshots to preserve > electrons. If you don't have qbzr installed you can replace 'bzr > qlog' by 'bzr viz' (if you have bzr-gtk installed). And if you > have neither, well, I can send you the screenshots :0) > > John =:-> -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAksrmnkACgkQJdeBCYSNAANcdQCgjB2Z4JKIkQOJ0SjG7vg1bLv0 R3oAnRML3TzF/fr9/SJQM9TlUG7n/lmT =CcCN -END PGP SIGNATURE-
Re: Recipes vs. Looms vs. pipelines
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 irrelevant to the discussion.
So what I meant is shown below (you can paste the following in
bzrlib/tests/test_script.py and run
bzr selftest -s bt.test_script.TestGraphs).
More than two threads needs to be involved of course.
class TestGraphs(script.TestCaseWithTransportAndScript):
def test_with_loom(self):
self.run_script("""
$ bzr init loom
$ cd loom
$ bzr nick trunk
$ bzr loomify
$ bzr commit -m trunk1 --unchanged
$ bzr create-thread vila
$ bzr commit -m vila1 --unchanged
$ bzr create-thread jam
$ bzr commit -m jam1 --unchanged
# New upstream version
$ bzr down-thread trunk
$ bzr commit -m trunk2 --unchanged
# Bring in new upstream
$ bzr up-thread --auto
$ bzr qlog
""")
def test_with_branches(self):
self.run_script("""
$ bzr init trunk
$ cd trunk
$ bzr commit -m trunk1 --unchanged
$ cd ..
$ bzr branch trunk vilajam
$ cd vilajam
$ bzr commit -m vila1 --unchanged
$ bzr commit -m jam1 --unchanged
# New upstream version
$ cd ../trunk
$ bzr commit -m trunk2 --unchanged
# Bring in new upstream
$ cd ../vilajam
$ bzr merge ../trunk
$ bzr commit -m 'Merge trunk into branch'
$ bzr qlog
""")
Gee, 13 and 14 commands respectively for the simplest example :-(
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 --auto' stops in case of conflicts
for a good reason.
The graphs are different because more information is preserved in
the loom case, that's basically the same argumentation about
rebase or not rebase, these additional commits may seem spurious
but that's a different debate.
Putting that back in the udd context means that you get a chance
to resolve the conflicts from upstream (there shouldn't be any
since we do a pull and we can do that because we preserved the
starting point) before resolving the conflicts from each patch,
the conflicts from debian and finally the conflicts from ubuntu.
Vincent
P.S.: I don't attach the 40kB screenshots to preserve
electrons. If you don't have qbzr installed you can replace 'bzr
qlog' by 'bzr viz' (if you have bzr-gtk installed). And if you
have neither, well, I can send you the screenshots :0)
--
ubuntu-distributed-devel mailing list
ubuntu-distributed-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Recipes vs. Looms vs. pipelines
-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 graphs are different, so the > histories are different. > > trunk -- my changes -- trunk merged >\ new trunk / > > trunk -- new trunk -- trunk merged >\ my changes / > > Different graphs. Same resulting trees. > > Another key difference between pulling trunk in the base thread > is that, when I use several threads and I do up-thread --auto, I > resolve the conflicts for each thread, in several steps > (partitioning the conflicts), which is generally easier and > cleaner. And again, since there are now several commits, I hope > we can more easily agree that the histories are even more > different ! > > Vincent > Maybe you and I are using different versions of bzr-loom. I just did this: bzr init test cd test bzr nick base bzr loomify bzr commit -m one --unchanged bzr create-thread next bzr commit -m next --unchanged bzr down-thread bzr commit -m "base two" --unchanged bzr up-thread --auto And it merged 'base two' into the 'next' thread, in the same way I would have done it, if I had done "bzr merge ../base; bzr commit". See the attached qlog screenshot. That clearly looks (to me) like trunk -- my changes -- trunk merged \ new trunk / John =:-> -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAksqlEIACgkQJdeBCYSNAANSZgCdHXv3j01+4oRENZjYJoFk+Mfq XYAAoJnW68qF2tA98dHonog1/xTlpic9 =MuYD -END PGP SIGNATURE- <>-- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Recipes vs. Looms vs. pipelines
-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 a loom with two threads, one the base thread and one your actual development. In the loom case, you do "bzr diff -r thread:" to view the difference. In the branch case, you do "bzr diff -r submit:" to view the difference. I think the two are equally easy. > 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 especially if you've got several > trunk merges interspersed. Sure, I can see the virtue of a stack-based approach if you want to view the work separately. But this doesn't help me understand why you would want trunk as the base thread. I have thought about implementing a diff that ignores changes introduced by merges. It's just a matter of tuits. > Updating the bottom thread and up-threading --auto falls into this. > It's usually a trivial, inconsequential afterthought. Most changes > on trunk don't affect my work, so I don't care about them. I'm > merging trunk to be diligent. The fact that I can mentally segregate > that to the bottom thread helps me ignore it completely in the common > case, even if the end result is the same. I don't see how this lets you mentally segregate it to the bottom thread. up-thread --auto affects all threads. > Supporting the type of workflow I describe above in > core bzr would be a win. It's all about fitting the model I have for > developing software, which really boils down to: tell me what I > changed As above, I think the branch-base workflow does tell you what you changed. >, ignore what other people changed unless it affects my > change - -r submit: does this > and help me organize my changes into tasks. At that point, you want a stack, but it doesn't need to have a trunk thread. >>> One of the other things that just rubs me wrong about pipelines >>> is that they require lightweight checkouts. I can't explain it, >>> but lightweight checkouts have just never felt "right" to me. >> A loom essentially has a lightweight checkout-- it's just >> implemented differently. It is a working tree that you use "bzr >> switch" to switch between different named heads. > > But it feels heavyweight because my branches are right there in the > directory containing my working tree. If bzr-pipeline used heavyweight checkouts, you would still need to have branches somewhere else. It would just mean that the tree would have a copy of whatever branch you were currently working on. > 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 completely done with it. This is actually co-location of trees with their branches. You can accomplish this with lightweight checkouts by putting the branch inside the .bzr directory of the branch. $ bzr init foo Created a standalone tree (format: 2a) $ bzr checkout foo bar $ mkdir bar/.bzr/branches $ mv foo bar/.bzr/branches/ $ cd bar $ bzr switch --force .bzr/branches/foo Tree is up to date at revision 0. Switched to branch: /home/abentley/sandbox/bar/.bzr/branches/foo/ Obviously, this is more steps than it should be, but it would be easy to turn into a reconfigure operation. > I should note thought that there's a wart in looms related to this: > export-loom. If I have to share my loom threads with others (e.g. a > merge proposal), I have to export it into separate branches. You can also use import-loom to convert it to a pipeline, which will preserve ordering information, so it can be used by lp-submit. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksqd7kACgkQ0F+nu1YWqI0otQCcCVk0ODm2GSmQKaehK/FJE5Ib APsAn2YerKa4onpSqHhLjLlxcWhyBvHX =lyKu -END PGP SIGNATURE- -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Recipes vs. Looms vs. pipelines
> "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 merged \ new trunk / trunk -- new trunk -- trunk merged \ my changes / Different graphs. Same resulting trees. Another key difference between pulling trunk in the base thread is that, when I use several threads and I do up-thread --auto, I resolve the conflicts for each thread, in several steps (partitioning the conflicts), which is generally easier and cleaner. And again, since there are now several commits, I hope we can more easily agree that the histories are even more different ! Vincent -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Recipes vs. Looms vs. pipelines
-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 loom case, the mirror is the bottom thread. In the non-loom case, it is ../devel. If we assume that the mirrors are not stale when you merge, or are equally stale, then they will have the same tip revision as one another. Therefore, you are merging the same revision either way. > Aaron> In the loom case, you are using "up-thread -a" to > Aaron> merge from your base-thread mirror. > > Which has been updated by the pull. So up-thread --auto will > create new revisions by merging each thread on top of that, the > trunk starting as the left-hand parent No, trunk's tip will be a right-hand parent in the top thread and the last_revision in the bottom thread. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksqbaYACgkQ0F+nu1YWqI23gwCfS8b6RIDqqgE9IKzYw+imHDBk 6gYAn08LkqZj1DDMBl4s4EZZelazsH+a =6B/a -END PGP SIGNATURE- -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Recipes vs. Looms vs. pipelines
> "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. >> >> In one case I *pull* trunk in the base thread while in the other >> I *merge* trunk in the top thread. Aaron> In both cases, you are merging the same revision into Aaron> the top thread. No. Aaron> In the loom case, you are using "up-thread -a" to Aaron> merge from your base-thread mirror. Which has been updated by the pull. So up-thread --auto will create new revisions by merging each thread on top of that, the trunk starting as the left-hand parent Aaron> In the non-loom case, you are using "merge;commit" to Aaron> merge directly from trunk. Yes on top of the existing commits where the trunk will now be a right-hand parent. Aaron> How can the history be different if you're merging the Aaron> same revision into the same line-of-development? I'm not merging the same revision and I'm not merging in the same line-of-development either. Besides I strongly expect the histories to be different as the two operations *are* different and don't carry the same intent. Vincent -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Recipes vs. Looms vs. pipelines
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 pullbzr commit -m'Merge rocketfuel' >barry> bzr up-thread --auto > > Nice, I never put words on that but I share the feeling. In my > mental model the "loom way" is: let's restart what I'm doing > based on today's trunk, whereas the "non-loom" way is: let's see > what happen if I bring trunk into my branch. Yes. I think you've gotten pretty close to the mental model I have. -Barry -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Recipes vs. Looms vs. pipelines
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 think that there are significant improvements to the command set: > > In loom, up-thread and down-thread are asymmetric. The analogue of > down-thread is switch-pipe, and the analogue of up-thread --auto is pump. > > The command for removing a pipe is called "remove-pipe", whereas the > command for removing a thread is called "combine-thread". > > pipeline has lp-submit to submit a merge proposal for a pipe to > Launchpad. It is impossible to submit a merge proposal for a thread to > launchpad, because threads aren't addressable. > > pipeline provides pipe-patches, to export the pipeline as a series of > patches. Ultimately what both pipes and looms gives me is a way to organize the subtasks I have to perform when developing a piece of software. They let me answer questions and produce output based on those subtasks instead of the more-granular revisions. Both looms and pipelines feel like bolt-ons to support this kind task-based workflow, so pulling those features and supporting those use-cases in core bzr would be a good long-term goal. -Barry -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Recipes vs. Looms vs. pipelines
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-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Recipes vs. Looms vs. pipelines
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 >> >> bzr down-thread rocketfuel bzr merge ../devel >> bzr pullbzr commit -m'Merge rocketfuel' >> bzr up-thread --auto > > I don't understand. The non-loom form is faster and requires fewer > commands. Why do you prefer the loom form? > > The pipeline version is even fewer commands: > > bzr pump --from-submit I know. I said it was difficult to explain! ;) I think Vincent came the closest to describing why the loom approach feels better than the non-loom (leaving out pipelines for the moment). With the loom approach, I can much better organize my thoughts and tasks. I have the thing I started with unchanged at the bottom. I have my initial work next. I have the results of my review next. Then I have any additional work I had to do to actually land the thing. It's all nice and neat and I can very easily find exactly the changes between any two of those tasks. 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 especially if you've got several trunk merges interspersed. Updating the bottom thread and up-threading --auto falls into this. It's usually a trivial, inconsequential afterthought. Most changes on trunk don't affect my work, so I don't care about them. I'm merging trunk to be diligent. The fact that I can mentally segregate that to the bottom thread helps me ignore it completely in the common case, even if the end result is the same. > Also, note that you don't need "../devel" in most cases. Yep, that was mostly just for example purposes. >> See above for the specific answer: normal branches in fact do not feel as >> natural to me > > Okay, so just to telegraph this, you actually feel there are > deficiencies with a branch-based workflow. This is something that we > should try to fix in core bzr, and if we do, that should also fix pipelines. Yep, see above. Supporting the type of workflow I describe above in core bzr would be a win. It's all about fitting the model I have for developing software, which really boils down to: tell me what I changed, ignore what other people changed unless it affects my change, and help me organize my changes into tasks. >> One of the other things that just rubs me wrong about pipelines is that they >> require lightweight checkouts. I can't explain it, but lightweight checkouts >> have just never felt "right" to me. > > A loom essentially has a lightweight checkout-- it's just implemented > differently. It is a working tree that you use "bzr switch" to switch > between different named heads. But it feels heavyweight because my branches are right there in the directory containing my working tree. 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 completely done with it. I do this when my changes have landed. I should note thought that there's a wart in looms related to this: export-loom. If I have to share my loom threads with others (e.g. a merge proposal), I have to export it into separate branches. This is a bit ugly, but it's manageable because I export all my looms to a separate parent directory that I can easily delete once I'm done with it, and it's very easy for me to identify which loom directory the export is associated with (by name). So while I'm not crazy about this step, it's not a feature killer for me. -Barry -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Conflict resolution workflow (was Re: Recipes vs. Looms vs. pipelines)
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 not insignificant amount of work. I'm sitting in a branch with lots of uncommitted changes due to the merge. I can't commit that until I've resolved the conflicts, but once I do, I have no way to know what part of that work came from the trunk merge and what part of the work came from my resolution of the conflicts. I would like to split this task into two parts. I want a revision that is the results of the merge of trunk, and a separate revision that includes just my changes to resolve the conflict. With that it would be much easier to identify, diff, review, and modify just the changes I had to make to resolve the conflict. It's entirely possible that I didn't resolve the conflict correctly the first time. Does bzr have tools to help me with this? -Barry -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Recipes vs. Looms vs. pipelines
-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> > barry> bzr down-thread rocketfuel bzr merge ../devel > barry> bzr pullbzr commit -m'Merge rocketfuel' > barry> bzr up-thread --auto > >> > No. down-thread , pull, up-thread is the same as "bzr merge" - --auto will do a commit for you. How is the history different? > > jam> What you are describing "verbally" sounds a lot more > jam> like the rebase workflow. Where you bring in trunk at > jam> the 'bottom' of your changes and put them all on top. > > Yes, except for the history-lost part of rebase. > > jam> I guess if you have more than 1 feature thread the > jam> history might be different. > > No. A base thread for trunk were I can pull and feature thread on > top is enough. > > In one case I *pull* trunk in the base thread while in the other > I *merge* trunk in the top thread. That's enough to build > different histories. > > Vincent > Nope. You still have to merge it into your top thread and commit that. So the history in the top thread is the same. John -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAksqW+wACgkQJdeBCYSNAAOzfgCgqWTkgef1gU5kR3/qhsoHpTEy J8MAoLqfzEw5RQFPcm7hc+7UAFJMLBQF =TXoG -END PGP SIGNATURE- -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Recipes vs. Looms vs. pipelines
-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 in the base thread while in the other > I *merge* trunk in the top thread. In both cases, you are merging the same revision into the top thread. In the loom case, you are using "up-thread -a" to merge from your base-thread mirror. In the non-loom case, you are using "merge;commit" to merge directly from trunk. How can the history be different if you're merging the same revision into the same line-of-development? Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksqVmsACgkQ0F+nu1YWqI08ZACfbX3aEa0CbN6K1ZMSlfKJ7VXe vU4AnRcDaG2P7yTife2cY3hwodwuOm7q =5hNb -END PGP SIGNATURE- -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Recipes vs. Looms vs. pipelines
> "jam" == John Arbash Meinel writes: jam> Vincent Ladeuil wrote: >>> "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 up-thread --auto >> >> Nice, I never put words on that but I share the feeling. In my >> mental model the "loom way" is: let's restart what I'm doing >> based on today's trunk, whereas the "non-loom" way is: let's see >> what happen if I bring trunk into my branch. >> >> Or said otherwise: one inject the new trunk from the bottom when >> the other inject it from the top. >> >> Of course the resulting tree is the same, but since they produce >> different histories, the resulting branches tend to behave a bit >> differently too when you start landing part of your work on the >> trunk and that you re-inject the trunk >> >> Vincent >> jam> Actually, those produce the exact same history. No. jam> What you are describing "verbally" sounds a lot more jam> like the rebase workflow. Where you bring in trunk at jam> the 'bottom' of your changes and put them all on top. Yes, except for the history-lost part of rebase. jam> I guess if you have more than 1 feature thread the jam> history might be different. No. A base thread for trunk were I can pull and feature thread on top is enough. In one case I *pull* trunk in the base thread while in the other I *merge* trunk in the top thread. That's enough to build different histories. Vincent -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Recipes vs. Looms vs. pipelines
-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 > barry> bzr pullbzr commit -m'Merge rocketfuel' > barry> bzr up-thread --auto > > Nice, I never put words on that but I share the feeling. In my > mental model the "loom way" is: let's restart what I'm doing > based on today's trunk, whereas the "non-loom" way is: let's see > what happen if I bring trunk into my branch. > > Or said otherwise: one inject the new trunk from the bottom when > the other inject it from the top. > > Of course the resulting tree is the same, but since they produce > different histories, the resulting branches tend to behave a bit > differently too when you start landing part of your work on the > trunk and that you re-inject the trunk > > Vincent > Actually, those produce the exact same history. What you are describing "verbally" sounds a lot more like the rebase workflow. Where you bring in trunk at the 'bottom' of your changes and put them all on top. I guess if you have more than 1 feature thread the history might be different. John =:-> -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAksqPicACgkQJdeBCYSNAANyCQCgyvIfx6PE4Azt6+DvWjCPLMkX u7EAn3UkUWCADEhMvOS8sUVd8DhAgoFJ =9WGm -END PGP SIGNATURE- -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Recipes vs. Looms vs. pipelines
> "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 up-thread --auto Nice, I never put words on that but I share the feeling. In my mental model the "loom way" is: let's restart what I'm doing based on today's trunk, whereas the "non-loom" way is: let's see what happen if I bring trunk into my branch. Or said otherwise: one inject the new trunk from the bottom when the other inject it from the top. Of course the resulting tree is the same, but since they produce different histories, the resulting branches tend to behave a bit differently too when you start landing part of your work on the trunk and that you re-inject the trunk Vincent -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Recipes vs. Looms vs. pipelines
-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 way that you *could* collaborate on-the-loom. Consider that the 'recipe' concept takes it to the extreme, where you just have a text file describing how to combine everything. > >>> 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. >> True, though this is significant in itself. (possibly solved by >> colocated branches, but visibility of branches is a genuine UI issue.) > > Agreed. > >> Creating something that makes it easier to get a change integrated into >> upstream, and then reflected back in your workspace seems a lot better >> statement. > > Okay, I can agree with that. > >> You can get close if we made cherrypicking really smart, but I'm not >> sure how smart you can make it, or really what that design looks like. > > Even something only as smart as 'tla replay' would be a great improvement. So if we wanted to hack something in today, we could create a 'bzr cherrypick' plugin that just records the revisions being pulled across as revision properties, and then adds a 'bzr cherrypick-replay' that would be, essentially, tla replay. It can then grab 'find_unique_ancestors' and look for ones that are actually merged, and then replay accordingly. One could replay the early revs that aren't merged, to create a new BASE that has all the rest, and then 3-way merge from there. It would at least be a way to experiment with it. Note also that you can get 'rejected' revisions in this system as well. And if the existing ancestry + rejected ancestry + merged ancestry ended up as a full merge, it could mark it as such. I think part of the issue is figuring out how to communicate from the time you did merge/cherrypick until the time you run 'bzr commit' what happened. (temp file somewhere on disk describing what happened.) > >> A >> DAG based loom/pipeline is something relatively easy to articulate. As >> it is what I do today with a pure-branch based flow without the >> 'up-thread'/'pump' helpers. > > Right, and in this vein, package branches start to look a lot like > integration branches. > > Aaron Yep. John =:-> -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkspaIUACgkQJdeBCYSNAAONUACeKZE7XWKoL82v45w8rH0dXZ3q qIUAn3ELtM4YaJtVJMe24cGpuvIcCPQ0 =29XE -END PGP SIGNATURE- -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Recipes vs. Looms vs. pipelines
-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 that threads tend to be less visible than branches. > > True, though this is significant in itself. (possibly solved by > colocated branches, but visibility of branches is a genuine UI issue.) Agreed. > Creating something that makes it easier to get a change integrated into > upstream, and then reflected back in your workspace seems a lot better > statement. Okay, I can agree with that. > You can get close if we made cherrypicking really smart, but I'm not > sure how smart you can make it, or really what that design looks like. Even something only as smart as 'tla replay' would be a great improvement. > A > DAG based loom/pipeline is something relatively easy to articulate. As > it is what I do today with a pure-branch based flow without the > 'up-thread'/'pump' helpers. Right, and in this vein, package branches start to look a lot like integration branches. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkspWuIACgkQ0F+nu1YWqI3WLgCfXd7JjOvz3d4leL5RnWtYMvRi 3pkAnRIZbPl4XQWOiXR78AT/xgLH3mLS =a49E -END PGP SIGNATURE- -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Recipes vs. Looms vs. pipelines
-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 always add it there. Right, it's not a trump card. But in my view, adding configuration data to threads basically makes them colocated branches, and having two kinds of branches that work very differently is unnecessarily complicated. > From my little understanding, I get the impression that pipelines are > more for organising your local work, rather than for collaboration > on a set of changes, which is why I haven't given them the attention > until now. However, it sounds like that may be more of an artifact of > not having co-located branches than part of the design. I wanted to focus on making pipelines a really good way of organizing local work. At the same time, I had noticed that people seemed to find the loom methods of collaboration confusing, saying thinks like "But *when* should I record?", and "why doesn't push work?". So I decided to do syncing using an unversioned list of pipes rather than a loom-style snapshot, and to provide a new "sync-pipeline" command instead of overriding push and pull. > I have just read http://wiki.bazaar.canonical.com/BzrPipeline, and > I feel like I understand the workflow a little better now. To my > reading it differs little from loom though, different analogy, > "push" rather than "pull" Actually, "sync-pipeline" rather than "push" or "pull". >, branches not proto-branches. Am I missing > something? 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. I think that there are significant improvements to the command set: In loom, up-thread and down-thread are asymmetric. The analogue of down-thread is switch-pipe, and the analogue of up-thread --auto is pump. The command for removing a pipe is called "remove-pipe", whereas the command for removing a thread is called "combine-thread". pipeline has lp-submit to submit a merge proposal for a pipe to Launchpad. It is impossible to submit a merge proposal for a thread to launchpad, because threads aren't addressable. pipeline provides pipe-patches, to export the pipeline as a series of patches. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkspWAkACgkQ0F+nu1YWqI14zgCeLFoRPzBRVSGqq+sIb/WfAafg enoAn1etdoa6S87JY9VcvWonSzd7UT3t =yEOz -END PGP SIGNATURE- -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Recipes vs. Looms vs. pipelines
-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 can only participate in one pipeline. > > With looms, this works because the loom thread is a mirror of upstream. > The analogue with pipeline is to have a mirror of upstream in the pipeline. > >> Going further, that also is a fairly significant difference between the >> *goals* of looms versus pipelines. > > You didn't actually name differences in the goals, so it's hard to > respond to this. AIUI, being able to share pipelines is not one of your goals. > >> Namely, I think "recipes" wants to be >> able to share a branch as part of the build process. Otherwise you end >> up with a huge proliferation of branches. (I want to build Foo with all >> these Ubuntu patches, and just add my one patch at the end.) > > 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. True, though this is significant in itself. (possibly solved by colocated branches, but visibility of branches is a genuine UI issue.) ... >> Thinking about the 'ideal' workflow, I don't think having a tool that >> lets you get to the point where you can create a nice patch and apply >> it, is the ideal end goal of packaging and UDD. > > I'm not sure what you mean here. Without a DAG, if you want out-of-order selection of changes, then you need cherrypicking. This is often done as a diff + patch. (Or bzr merge with a range, but that is effectively a slightly smarter diff + patch.) 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. Creating something that makes it easier to get a change integrated into upstream, and then reflected back in your workspace seems a lot better statement. So having the stack broken, which allows upstream to 'bzr merge' just one thread/pipe/branch without getting the other unwanted changes, which then comes in through your upstream branch, and bubbles up naturally (without conflicting from duplicate changes, etc.) You can get close if we made cherrypicking really smart, but I'm not sure how smart you can make it, or really what that design looks like. A DAG based loom/pipeline is something relatively easy to articulate. As it is what I do today with a pure-branch based flow without the 'up-thread'/'pump' helpers. > >> I suppose the other alternative is to do better cherrypicking support in >> bzr, though they are a bit orthogonal. (You'll always want better >> cherrypicking support, as you won't always have factored everything out >> cleanly at first, etc.) > > +1 on better cherrypicking support. > > Aaron I find the biggest problem being defining what "better" really means. In terms of data representation, and actual effect. We can say "we should be able to do better than this", but the details are really quite difficult. John =:-> -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkspTVQACgkQJdeBCYSNAANsMQCeKBHvJH8XjvoUlv5Und51c5eB 8xYAn0HlMqKazzdYCJ7US43G31dVUCG2 =FGP8 -END PGP SIGNATURE- -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Recipes vs. Looms vs. pipelines
-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 that I want control over when I update the bottom thread >>> independently of when I update the devel branch. >> What advantages does that gives you? Do you find you miss those when >> working on non-loom branches? > > It allows me to very easily merge changes that are happening all the time on > devel with my feature or bug fix, but on my schedule. I don't understand what the advantage of a loom over a branch is. The merge should be just as easy with a branch. A branch should also allow you to do it on your schedule. > I might update the > Launchpad devel branch while I'm in the middle of my bug fix, for various > reasons (e.g. I'm working on more than one branch at a time, I want to see how > "pristine" trunk works, etc.). When my branch is ready for review, I want to > pull in devel's updates and merge them up my stack. Again, I don't understand how this is any different with a branch. > 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 > > bzr down-thread rocketfuel bzr merge ../devel > bzr pullbzr commit -m'Merge rocketfuel' > bzr up-thread --auto I don't understand. The non-loom form is faster and requires fewer commands. Why do you prefer the loom form? The pipeline version is even fewer commands: bzr pump --from-submit Also, note that you don't need "../devel" in most cases. >>> This is something that feels more natural to me in looms than in pipelines. >> bzr-pipeline is meant to allow you to use your normal development habits >> as much as possible. In fact, a normal branch is also a pipeline with a >> single pipe. When you are normally working on a normal branch, the lack >> of an upstream pipe should feel perfectly natural, so why does it feel >> less natural when you add a second pipe? > > See above for the specific answer: normal branches in fact do not feel as > natural to me Okay, so just to telegraph this, you actually feel there are deficiencies with a branch-based workflow. This is something that we should try to fix in core bzr, and if we do, that should also fix pipelines. > One of the other things that just rubs me wrong about pipelines is that they > require lightweight checkouts. I can't explain it, but lightweight checkouts > have just never felt "right" to me. A loom essentially has a lightweight checkout-- it's just implemented differently. It is a working tree that you use "bzr switch" to switch between different named heads. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkspP/IACgkQ0F+nu1YWqI2HgwCdEWc5NOPfFBlCAHNdKJb1IlpM hL4An3Z7zpe4XBFKTxeZZfFOuwlScuVX =/Vx0 -END PGP SIGNATURE- -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Recipes vs. Looms vs. pipelines
-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 possible. Is there something holding you back? Not really. I remember you mentioning that this is possible now, so I'll make sure to give pipelines another try with this in mind. Thanks, - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iQIcBAEBCAAGBQJLKTkRAAoJEBJutWOnSwa/I7AQAJ2Q1e2rbMwONcta1ibkYJKV RoSz9l6yw51IUd/mkBkul1SE2aiNAYK1ectwa059iaRx5hVqfUr4246ebo0/6vRc Q9AQHgc0tBHf+fT8Q12tTpbiPBUSqGqvZsZi23vqBNZggwy3PWOU/coqEoGdX2uK ij+S0+nwYgjWqEI6Rw/xuSTL4OddvCEwRNeqZfNZJMWDpsI/CS7R6Dl9IYWGmOlf V5t5xijbZsHnViVwOodtqWs+ru/RQ/BYm6ScjFGYS21tpzinFCE23t0MucpElh5e jmEPlpFHO4oykKBWyWETswxsleLWlaRyd57FrRR/m5SYe/BMoADDSnVF6Ar7+1d/ y0iixHo9lVE4PRFjorp3VtF1k3gyCnqo10HQozXfWglRwP2oPRUGVILrJrZJ8zsv 2lJg8zFNEVhQZPle8JtaMoemwQsLA8bD2nQvX1gaqX+t35inaITyqTl/lqKtLRxU JapIMz4ywXMsqqMiFinBAJoaIB7v5h8slIH2WK5LoKmpRMRmGtz0CIl11XGY9+Wn WjjjThyDoPjjpmgMsycw9OkeApIyUXzkerOeeGtLvGlSjFSq1pHpbSXuzEsOuqny h2kdXbWIBJ4raZSwaNAHQlhS1ujwUNfSVnlZ1xIS0LwZ2OptHMcm/0q9EQXPNjSF t+m654brwT4vyg5CwF0s =IODu -END PGP SIGNATURE- -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Recipes vs. Looms vs. pipelines
-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 I update the bottom thread >> independently of when I update the devel branch. > >What advantages does that gives you? Do you find you miss those when >working on non-loom branches? It allows me to very easily merge changes that are happening all the time on devel with my feature or bug fix, but on my schedule. I might update the Launchpad devel branch while I'm in the middle of my bug fix, for various reasons (e.g. I'm working on more than one branch at a time, I want to see how "pristine" trunk works, etc.). When my branch is ready for review, I want to pull in devel's updates and merge them up my stack. 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 - bzr down-thread rocketfuel bzr merge ../devel bzr pullbzr commit -m'Merge rocketfuel' bzr up-thread --auto >> This is something that feels more natural to me in looms than in pipelines. > >bzr-pipeline is meant to allow you to use your normal development habits >as much as possible. In fact, a normal branch is also a pipeline with a >single pipe. When you are normally working on a normal branch, the lack >of an upstream pipe should feel perfectly natural, so why does it feel >less natural when you add a second pipe? See above for the specific answer: normal branches in fact do not feel as natural to me, though I often forgo looms for expediency when I'm working on a simple or quick fix. It's a decision I have to make upfront and I don't always get it right (for example, the branch becomes more complex than I expected, or I get distracted in the middle of it for a few days). One of the other things that just rubs me wrong about pipelines is that they require lightweight checkouts. I can't explain it, but lightweight checkouts have just never felt "right" to me. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iQIcBAEBCAAGBQJLKTi/AAoJEBJutWOnSwa/HDwP/3xil6KGRLm/TC8Nc2zG6sM1 OO1T+wsk6ITgrCkEWhKHB4QTemv3G9kppPxIbYPyYpc8KQUpnk5bJ/JRr6ntHeLV UiNB55FiPHidE2EmcaIwUrmUvJFHaugOnsng0oTzGgpLsiznott1pzPx+zkZ6EYd ouPHIOPzEQUe3O3Y7cVu6NhVKxN011qXcFoH5+DY3DICT1e65WLkw/lCD6dfuJ1p Tr2lyZYZulGDHt059wlMK0eSYSz8xtOrJhrJj/pd05rFNdB/WO8J5nkqxiEr3k6u UnJR+NlFeDTw+wG6caGHq8/7IBm08OiKfb/Ib3VtCrK88WefRce8dV9ZnggB0lvP tuSyTUYG5fcnHTVC8GZ+UzwqxvkLGd2XtSJiGwWR8f9EnBDrgxz4afN+9tEDZRCf 6QO9PVYvGUA2ZAlo1cdjFMd9v2rMCddhhgyIRsKrYFkFbj7zWUgD/prTGdzr1VBH tsYPJIi8PmImkqSAi9FkCTMWsaSLaH7RiJPSUgolQaIH98X8MwWEfKWeSVzGy6oS BsieKx8dpCZSeIzuP4z9x8lt7xpQeEMKsAz41vH1fuVtAjpjTH+WXt0T5FqVUerg LRO5uYnQYUwtSq4dTFjU+33VCz3CCXdaaNjHb5HE94a2EFl1ZnEIvCKV3E6cnxP5 ldr/7dBH85H1PcAzmRIg =e04o -END PGP SIGNATURE- -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Recipes vs. Looms vs. pipelines
-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 SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkspM0cACgkQ0F+nu1YWqI0M3gCeO8Bck9/YDO1oKsqMwbYYrrRJ 1AUAn0uFulWsGC/55ALbP2v7fTENco3S =75S5 -END PGP SIGNATURE- -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Recipes vs. Looms vs. pipelines
-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 update the devel branch. What advantages does that gives you? Do you find you miss those when working on non-loom branches? > This is something that feels more natural to me in looms than in pipelines. bzr-pipeline is meant to allow you to use your normal development habits as much as possible. In fact, a normal branch is also a pipeline with a single pipe. When you are normally working on a normal branch, the lack of an upstream pipe should feel perfectly natural, so why does it feel less natural when you add a second pipe? Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkspMuAACgkQ0F+nu1YWqI3aUwCfQ0XdB0FiJJ4WMtlxjaWFvvs9 PfwAn2id3LPcOsZvtILPczLpM4Ga2R2C =mK3N -END PGP SIGNATURE- -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Recipes vs. Looms vs. pipelines
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 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. -Barry signature.asc Description: PGP signature -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Recipes vs. Looms vs. pipelines
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 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 update the devel branch. This is something that feels more natural to me in looms than in pipelines. >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 all of your other changes. Otherwise the loom is just there to >help you develop the patch. And then you throw away all the history once >the patch gets applied to upstream. I'm being more convinced of this as these discussions proceed. Having a DAG would, I think, resolve some of the trickier branches I've developed with looms. I agree with James that the ui is difficult though. -Barry signature.asc Description: PGP signature -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Recipes vs. Looms vs. pipelines
-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 pipeline. With looms, this works because the loom thread is a mirror of upstream. The analogue with pipeline is to have a mirror of upstream in the pipeline. > Going further, that also is a fairly significant difference between the > *goals* of looms versus pipelines. You didn't actually name differences in the goals, so it's hard to respond to this. > Namely, I think "recipes" wants to be > able to share a branch as part of the build process. Otherwise you end > up with a huge proliferation of branches. (I want to build Foo with all > these Ubuntu patches, and just add my one patch at the end.) 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. > Which (IMO) is something that pushes for having a real DAG in the loom > state, rather than just a stack model. > You'd run into the same issue with pipelines, since they are also a > simple stack. This is something that's been requested for pipelines as well. I have similar concerns to the ones James expressed about a DAG being harder to work with, but I'm still considering it. > Thinking about the 'ideal' workflow, I don't think having a tool that > lets you get to the point where you can create a nice patch and apply > it, is the ideal end goal of packaging and UDD. I'm not sure what you mean here. > I suppose the other alternative is to do better cherrypicking support in > bzr, though they are a bit orthogonal. (You'll always want better > cherrypicking support, as you won't always have factored everything out > cleanly at first, etc.) +1 on better cherrypicking support. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkspJrkACgkQ0F+nu1YWqI1NKwCeKA78u8SYEwnWXy0WhDdJIEWf nvAAn0zWvmkTUWGXOwcz5/2lQENbi/WM =B5Us -END PGP SIGNATURE- -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Recipes vs. Looms vs. pipelines
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 are alternative models proposed, including > > a full DAG as implemented by TopGit. My fear is that they are > > too complicated for people to easily grasp, and that they are > > not the best way to solve the problems they aim to. > > > Looms on the other hand currently have no parent pointers > > per-thread. > > If you want something that implements the stack model and provides > parent pointers, we have that in bzr-pipeline. It doesn't provide the > same single-glob approach as loom, but that is mainly because bzr > doesn't yet provide colocated branches. We do want to add that support, > so maybe now is a good time to do it. > > > 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 fans, like rockstar and thumper. It is also under active development. > > > Looms also allow for versioning at the loom level, as well > > as at the revision level. This means that it is possible > > to merge a loom as a whole, including operations that > > add and delete threads. This is crucial to building a > > packaging system on top of them. > > These features are enbryonic in loom, and they could be added to > bzr-pipeline. Hi Aaron, Thanks for bring up pipelines, I haven't investigated them sufficiently before now. 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 always add it there. Having said that, I would be wrong to dismiss pipelines without a fair comparison, so let's do that. >From my little understanding, I get the impression that pipelines are more for organising your local work, rather than for collaboration on a set of changes, which is why I haven't given them the attention until now. However, it sounds like that may be more of an artifact of not having co-located branches than part of the design. I have just read http://wiki.bazaar.canonical.com/BzrPipeline, and I feel like I understand the workflow a little better now. To my reading it differs little from loom though, different analogy, "push" rather than "pull", branches not proto-branches. Am I missing something? That would then give points in favour of pipelines: * currently more actively maintained * real branches * more daily users (?) And in favour of looms: * currently able to make lp:ubuntu/foo a loom (co-located branches would nullify this) * Merging across the set is partly implemented. Is there anything else you would add? Thanks, James -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Recipes vs. Looms vs. pipelines
-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 fans, like rockstar and thumper. It is also under active development. > >> Looms also allow for versioning at the loom level, as well >> as at the revision level. This means that it is possible >> to merge a loom as a whole, including operations that >> add and delete threads. This is crucial to building a >> packaging system on top of them. > > These features are enbryonic in loom, and they could be added to > bzr-pipeline. > > Aaron 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. Going further, that also is a fairly significant difference between the *goals* of looms versus pipelines. Namely, I think "recipes" wants to be able to share a branch as part of the build process. Otherwise you end up with a huge proliferation of branches. (I want to build Foo with all these Ubuntu patches, and just add my one patch at the end.) 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 all of your other changes. Otherwise the loom is just there to help you develop the patch. And then you throw away all the history once the patch gets applied to upstream. You'd run into the same issue with pipelines, since they are also a simple stack. Thinking about the 'ideal' workflow, I don't think having a tool that lets you get to the point where you can create a nice patch and apply it, is the ideal end goal of packaging and UDD. I suppose the other alternative is to do better cherrypicking support in bzr, though they are a bit orthogonal. (You'll always want better cherrypicking support, as you won't always have factored everything out cleanly at first, etc.) John =:-> -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAksnxEYACgkQJdeBCYSNAAP/WwCgp39aN7bi3oSbfobEPR/KJwNl XP0AnjDDNWwt0eVV1JEWI64QxGWQXYQi =dBBa -END PGP SIGNATURE- -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Recipes vs. Looms vs. pipelines
-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 by TopGit. My fear is that they are > too complicated for people to easily grasp, and that they are > not the best way to solve the problems they aim to. > Looms on the other hand currently have no parent pointers > per-thread. If you want something that implements the stack model and provides parent pointers, we have that in bzr-pipeline. It doesn't provide the same single-glob approach as loom, but that is mainly because bzr doesn't yet provide colocated branches. We do want to add that support, so maybe now is a good time to do it. > 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 fans, like rockstar and thumper. It is also under active development. > Looms also allow for versioning at the loom level, as well > as at the revision level. This means that it is possible > to merge a loom as a whole, including operations that > add and delete threads. This is crucial to building a > packaging system on top of them. These features are enbryonic in loom, and they could be added to bzr-pipeline. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksnvzIACgkQ0F+nu1YWqI2c3QCfTIYP4JAbYm2GzmRHvtTCRcTx KOIAmgOyOKNshnArCZZFkUPxcyQbMUXt =UxX7 -END PGP SIGNATURE- -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
