User: Password:
|
|
Subscribe / Log in / New account

Bazaar on the slow track

Bazaar on the slow track

Posted Sep 13, 2012 7:51 UTC (Thu) by mbp (guest, #2737)
In reply to: Bazaar on the slow track by Cyberax
Parent article: Bazaar on the slow track

bzr's model is a DAG with special emphasis given to the path from the branch tip back to the origin through left-hand ancestors. It's quite mathematical and not that hard to understand.

In many projects, after a patch/feature/fix is merged to trunk, the history of just how that patch was written becomes relatively unimportant: to start with, people looking at history just want to see "jdoe fixed bug 123". One approach is to literally throw that history away and just submit a plain patch, as is often done with git. I wanted to try something different that would keep all the history, but also have a view of which path through the dag was the main history. (You can also do the prior one in bzr of course.)

The other major difference with bzr is that revisions are hashed for integrity, but primarily identified by assigned ids. This avoids transitions when the representation changes and allows directly talking about revisions in foreign systems. But, hash or not, they still have globally unique ids.


(Log in to post comments)

Bazaar on the slow track

Posted Sep 13, 2012 19:42 UTC (Thu) by dlang (subscriber, #313) [Link]

> One approach is to literally throw that history away and just submit a plain patch, as is often done with git. I wanted to try something different that would keep all the history, but also have a view of which path through the dag was the main history.

note that git doesn't force you to throw away the history.

If you pull from the mainline, create your patch, and send a pull request, your history will show up in the main repository.

you can even edit your patch history prior to sending the pull request. This is commonly done by people doing major changes as it lets them clean things up and make each patch 'correct' and self contained rather than showing the reality where one patch may introduce a bug that's fixed several patches later.

the only question is defining "which path was the main history" because git really doesn't define a "main history".

Bazaar on the slow track

Posted Sep 19, 2012 14:22 UTC (Wed) by pboddie (guest, #50784) [Link]

note that git doesn't force you to throw away the history.

I think that the intention may have been to describe the apparently common practice, particularly amongst git-using projects, of aggressively rebasing everything and asking people to collapse their contributions into a single patch so that the project history is kept "clean".

Bazaar on the slow track

Posted Sep 19, 2012 15:31 UTC (Wed) by dlang (subscriber, #313) [Link]

one of the features of git is the ability to recreate and combine patches before pushing them upstream.

Yes, this can be abused to combine a huge amount of work into one monster patch.

But it can be used sanely to re-order and combine patches from a line of development into a clean series of logical patches.

When you are developing something, if you check it in frequently as you go along, you are going to have cases where you introduce a bug at one point and don't find and fix it for several commits. You are also going to have things that you do at some point that you find were not the best way to do something and that you change back later (but want to keep other work you have done in the meantime)

you now have the option of either pushing this history, including all your false starts, bugs, etc.

Or you can clean the history up, combining the bugfixes with the earlier patches that introduced the bug, eliminating the false starts, etc and push the result.

The first approach has the advantage that everything is visible, but it has the disadvantage that there are a lot of commits in the history where things just don't work.

If the project in question encourages the use of bisect to track down problems, having lots of commits where things just don't work makes it really hard for users trying to help the developers track down the bugs.

As a result, many projects encourage the developers to take the second approach.

Now, many developers misunderstand this to mean that they are encouraged to rebase their entire development effort into one monster patch relative to the latest head, but that's actually a bad thing to do.

And in any case, the history is still available to the developer, they are just choosing not to share that history with the outside world.

Bazaar on the slow track

Posted Sep 19, 2012 19:52 UTC (Wed) by smurf (subscriber, #17840) [Link]

What he said.

A "clean" history (meaning "to the best of my knowledge, every change transforms program X1 into a strictly better program X2") means that you can take advantage of one of git's main features when you do find a regression.

Bisecting.

If you do break something, "git bisect" requires ten compile-test-run cycles to find the culprit, among a thousand changes. Or twenty cycles if you have a million changes. (OK, more like 13 and 30, because history isn't linear, but you get the idea.) If you try to keep track of that manually you'd go bonkers.

Of course this isn't restricted to git. bzr and hg also implemented the command. The idea was too good not to. ;-)
I don't know how well they do in finding reasonable bisection points in a complex revision graph; git's algorithm is very good these days.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds