login
Header Space

 
 

2.6.27-rc2, "A Lot Of Random Changes"

August 7, 2008 - 2:44am
Submitted by Jeremy on August 7, 2008 - 2:44am.
Linux news

"So it's been a week since -rc1, and -rc2 is out there," began Linux creator Linus Torvalds, announcing the 2.6.27-rc2 Linux kernel. He noted, "there's a lot of random changes in there, and I'm hoping we're starting to calm down, but one particular _kind_ of random change is probably worth pointing out explicitly due to the things it can result in: the fact that a number of architectures ended up using the 'lull' after -rc1 (hah!) to do the 'include/asm-xyz' => 'arch/xyz/include/asm' renames." Linus explained that for people actively developing and merging code with git, "be aware that we've recently had more renames than the rename detection limit in git defaults to, and as a result, if you have a rename<->data change conflict, you may want to increase the default limit." Linus noted that developers with sufficient ram can set "renamelimit=0" to completely disable the limit, and others can set it to a high value such as 5,000, "the default limit is pretty low just to not cause problems for people who have less memory in their machines than kernel developers tend to have..."

Linus continued, "the dirstat (with rename detection on, so as to not show the movement as huge changes) is fairly usual, with most of the changes in drivers, along with an ext4 and xfs update making 'fs' show up pretty high too". He added:

"The shortlog is still a tad too big to make it on the list (again, as usual - normally I end up posting shortlogs for -rc3 and later when they become more manageable) but let me just say that it isn't really all that interesting. Theres' a lot of small changes here, but nothing that makes you go 'Wow!'. Not that there _should_ be anything like that in -rc2, of course, so I'm not complaining."


From: Linus Torvalds <torvalds@...>
Subject: Linux 2.6.27-rc2
Date: Aug 6, 1:14 am 2008

So it's been a week since -rc1, and -rc2 is out there.

There's a lot of random changes in there, and I'm hoping we're starting to 
calm down, but one particular _kind_ of random change is probably worth 
pointing out explicitly due to the things it can result in: the fact that 
a number of architectures ended up using the "lull" after -rc1 (hah!) to 
do the 'include/asm-xyz' => 'arch/xyz/include/asm' renames.

Now, that doesn't really matter for 99% of all people, but the very fact 
that there are a _lot_ of renames here (and more pending) can affect 
people who depend on git to do rename detection and merging of contents 
across renames.

So _if_ you use git to merge stuff, be aware that we've recently had more 
renames than the rename detection limit in git defaults to, and as a 
result, if you have a rename<->data change conflict, you may want to 
increase the default limit. Just add a 

	[diff]
		renamelimit=0

to your ~/.gitconfig to disable the limit entirely if you have lots of 
memory (or make it some high value like 5000 or something). The default 
limit is pretty low just to not cause problems for people who have less 
memory in their machines than kernel developers tend to have...

(Of course, you can just decide to do the merge resolution manually, but 
most people would prefer not to).

NOTE! For people who don't actually do development in git, and just use it 
to track the kernel tree by just updating from the same source all the 
time, this won't matter - you're not doing any merges, you're just fast- 
forwarding all the time and rename detection is immaterial since there can 
never be any conflicts to resolve.

Anyway, for somewhat the same reason, the diffstat isn't very readable. 
Even with rename detection enabled, there's a thousand lines of just 
things like

	rename {include/asm-sh/cpu-sh2 => arch/sh/include/cpu-sh2/cpu}/cache.h (88%)

etc (and obviously doing it _without_ rename detection is even less 
useful).

The dirstat (with rename detection on, so as to not show the movement as 
huge changes) is fairly usual, with most of the changes in drivers, along 
with an ext4 and xfs update making 'fs' show up pretty high too:

   3.9% Documentation/
   3.5% arch/mips/kernel/
   8.9% arch/mips/
   8.9% arch/
   4.0% arch/sh/
   4.1% arch/
  13.0% drivers/misc/sgi-gru/
  19.6% drivers/misc/sgi-xp/
  32.7% drivers/misc/
   4.2% drivers/net/wireless/
   7.6% drivers/net/
   5.8% drivers/regulator/
  56.7% drivers/
   8.6% fs/xfs/
  11.1% fs/
   6.5% include/

The shortlog is still a tad too big to make it on the list (again, as 
usual - normally I end up posting shortlogs for -rc3 and later when they 
become more manageable) but let me just say that it isn't really all that 
interesting. Theres' a lot of small changes here, but nothing that makes 
you go "Wow!". Not that there _should_ be anything like that in -rc2, of 
course, so I'm not complaining.

			Linus
--


I want rename detection!

August 7, 2008 - 10:15am

At work I have to use ClearCase, which has no rename detection, at least, not in the configuration we use. Couple that with the fact that only a VOB administrator can add a file, and the result is that renaming a file is a firing offense. I seriously have to work with files whose names make no sense whatsoever given their current purpose and contents, and they were named according to a convention that is quite literally lost to the mists of time.

I want rename detection! You git users really have it nice!

Shudder

August 7, 2008 - 12:22pm

We were going to get ClearCase in a company I worked for once. There were courses and everything. Luckily we never got to the point of deploying it. At the time it looked a better bet than our rather antiquated RCS system but these days a vendor would have to do a real convincing job to make me pay for a VCS.

--
Alex

Ah, well

August 7, 2008 - 12:55pm

Ah, well, at least the naming conventions used by the ancients produced such gems as "pisstart" and "pisstop" and we can claim that ClearCase is the reason we can't change them. :^)

Within clearcase, the

August 8, 2008 - 4:27am
Anonymous (not verified)

Within clearcase, the element (which is versioned) is distinctly different from its name (within a versioned directory).

The element move, and element rename, operations just change where the element is referenced within the VOB's directory structure.

Its only when elements are being moved across VOB boundaries that things get tricky.

As an example:

1) checkout a (versioned) directory element
2) rename a file element within that directory
3) commit the changed directory element, to generate a new version of that directory.

The actual file element never changed. In fact, its version tree is the same, right? Its the data within the directory element that changed.

Also, if you use the old version of the directory, the file element is still known by its old name. The same for any baseline (or label to use base clearcase jargon) that references that old version of the directory element. In general, tt is only the deletion of elements (or their versions) that destroys the integrity of baselines (or labels). To be pedantic, this includes moving elements between VOBs, hence the "it gets tricky" comment earlier.

It is only when you do an element copy that you actually create another element. Perhaps your site is implementing "rename" as "make a copy of the element" and not "just move the element around"? If you are using clearcase explorer, then "copy" and "paste" is element copy, while the "drag an element from the rightside pane, to the left (directory tree) pane" is actually an element move (with a confirm dialog popup).

When you perform element movement, you get rename detection, in that merges are within a particular element's version tree, irregardless of where that element is identified within the versioned directory structure.

In general, clearcase is a conceptual descendant of the unix filesystem model, upon which it was based. That work was done by Atria, which later became part of Rational, and then became part of IBM.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
speck-geostationary