Rick Hillegas wrote:
I would like to understand what code archaeology looks like after the
Homogenizing Event. I think that this will split codeline time into two
segments: Before Homogenization and After Homogenization. The
Homogenizer will appear as the author of a lot of our code. In tracing
the history of a file, you will have to cross-reference two subversion
clients, one rolled back Before Homogenization and one set at the
current level After Homogenization. Can this be simplified? Are there
tools that zipper the two views together?
Since we operate with a comitter role, svn praise/annotate/blame is
already quite useless when it comes to the author name. You must consult
the log to figure out who has really written the code anyway.
Personally, I don't have any problems dealing with a split in the
revision history, as long as this split is well defined (i.e. all white
space changes done in a specific revision [range]). But I'm not a
committer, I suppose you guys are more affected by this.
As time goes by, the problem will be less and less prudent.
We managed the repos change and the huge "touch-a-lot-of-files" eol
patch committed earlier, didn't we?
Fianlly, things won't be easier if we postpone this clean-up operation...
I think doing this just before we branch 10.2 has been mentioned as a
suitable time, and also applying the changes to the 10.1 branch as well.
--
Kristian
-Rick
Bernt M. Johnsen wrote:
Rick Hillegas wrote (2006-05-31 13:25:09):
Before injecting a massive singularity into our code archaeology, I
would like to better understand the passionate objection to tabs. Let
me explain my perspective: I use a crude, old-fashioned editor called
emacs. My tabs are configured at 4 space intervals. With this
setting, I almost never have a problem reading the existing code. So
who is having problems and why?
1) Some tools change code invisibly. E.g. Emacs will (at least in some
configurations) change from space to tabs or vice vers when you hit
the tab key.
2) Tabstops set to 4, as you do, requires all tools working with Derby
to be identically set up. I guess that never will happen.
3) Spaces are spaces and mey not be differently interpreted.
I use Emasc too (best IDE there is!) and have configured Emacs to fill
with spaces when I hit the tab key.
Do other people's IDEs silently bulk reformat the code?
It seems like some do.....
Can that behavior be disabled?
Well. Difficult to say. We deal with Emacs, XEamacs, netbeans,
Eclipse, vi, and a host of other tools/editors here.
Could we be satisfied with the following simple rules, which used to
satisfy us nine years ago:
1) Ladies and gentlemen, set your tabs to four spaces.
2) Don't bulk reformat other people's code.
I hope we are not headed into a religious war.
And: I don't hate tabs. But my nearly 30 years of programming have
taught me that spaces work better than tabs, but I can live with
both. What I dont *want* to live with (although I of course can), is
unnecessary white space changes when working with svn. Therefore, an
enforced standard would be welcomed by me.
[...]
