Version control question.

Version control question.

[Kaz Kylheku]

Is there any document that makes the linux-mips configuration management
structure more obvious?

I see that the 2.6.16 and 2.6.17 lines are in fact parallel branches, so
that 2.6.16.27 is newer than 2.6.17.

If something is broken in 2.6.17 but isn't in 2.6.16.27, what's the best
way to find it?

Just compare 2.6.16.27 to the closest parallel 2.6.17.x to see what the
differences are?

Version control question.

[Kaz Kylheku]

Is there any document that makes the linux-mips configuration management
structure more obvious?

I see that the 2.6.16 and 2.6.17 lines are in fact parallel branches, so
that 2.6.16.27 is newer than 2.6.17.

If something is broken in 2.6.17 but isn't in 2.6.16.27, what's the best
way to find it?

Just compare 2.6.16.27 to the closest parallel 2.6.17.x to see what the
differences are?

Re: Version control question.

[Ralf Baechle]

On Fri, Aug 11, 2006 at 02:31:49PM -0700, Kaz Kylheku wrote:

> Is there any document that makes the linux-mips configuration management
> structure more obvious?

There is http://www.linux-mips.org/wiki/Git.  If that doesn't answer
your questions, let me know what you're missing and if I find the time
I'll add it.  Or just add it yourself to the wiki.

> I see that the 2.6.16 and 2.6.17 lines are in fact parallel branches, so
> that 2.6.16.27 is newer than 2.6.17.

Right.

> If something is broken in 2.6.17 but isn't in 2.6.16.27, what's the best
> way to find it?

You can use git bisect to do that on a clean that is unmodified tree:

$ git bisect start
$ git bisect bad linux-2.6.17
$ git bisect good linux-2.6.16.27

git will then checkout a tree that is about in the middle between the
good and bad version.  Build and test it, then either tell git

$ git bisect good

or

$ git bisect bad

depending on the outcome of your test.  Continue you've shurnk the
interval to a single version which is when git will tell you which
commit broke things.

Once you're finished you tell git to cleanup the tree from all the
bisecting stuff:

$ git bisect reset

> Just compare 2.6.16.27 to the closest parallel 2.6.17.x to see what the
> differences are?

git bisect is handy for finding a change even for relative beginners,
while starring at a diff is often much faster.  You can get a diff
between two tagged versions in git like:

$ git diff linux-2.6.16.27..linux-2.6.17

  Ralf