-----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----- -- 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
