Source Control and Refactoring

Source Control and Refactoring

Post by Ilja Preu » Wed, 02 Jul 2003 18:08:04



Quote:> Get a tool like IntelliJ.  It automatically changes file names in CVS
> when you change class names.  It's also a kick-ass IDE!

Not if you are working with C# or Ruby, I guess... ;)

There are Eclipse-Plugins for those languages - don't know about their
usefullnes, though:
http://eclipse-plugins.2y.net/eclipse/plugins.jsp?category=Languages

 
 
 

Source Control and Refactoring

Post by Paul Sinnet » Thu, 03 Jul 2003 02:24:22



>>I have this book but I don't remember this. I had a quick scan through
>>but I couldn't see "one file solves a problem" referenced anywhere. Can
>>you point me to the chapter?

> Nope. Sorry. I lost the book years ago. But I (think I) learned a
> helluva lot from it.

> Maybe I should write down everything I think I remember about it, and
> publish that as a book.

So your argument from authority is really an argument from the memory of
authority.

 
 
 

Source Control and Refactoring

Post by Tobin Harri » Thu, 03 Jul 2003 05:01:25




> > having to remove/re-add the
> >correcsponding file to CVS

> Rename the class in the repository, instead.  I wouldn't suggest giving
> everybody rights to do this, however.

Hmmm, I suppose this could be a way forward, but a little bit of a pain to
go behind the back of the known and loved CVS command line! Also not good
when working remotely...

Tobes

 
 
 

Source Control and Refactoring

Post by Tobin Harri » Thu, 03 Jul 2003 05:12:28




Quote:> No you aren't lazy.  It's important to remove any impediment to
> improving your design.

> Get a tool like IntelliJ.  It automatically changes file names in CVS
> when you change class names.  It's also a kick-ass IDE!

I've heard alot about IntelliJ, I reckon these guys should write an
IntelliC#!! Maybe I could write a VS.NET plugin that takes care of this
renaming automagically. As far as I know, I'm stuck with:

1. DOS Copy file to new 'desired' name
2. CVS 'remove' old file (along with local version also)
3. CVS 'add' new file
4. CVS 'commit' new file

Hmm, perhaps a better question for a CVS newsgroup!?

Tobes

> Robert C. Martin  | "Uncle Bob"

> PO Box 5757       | Tel: (800) 338-6716
> 565 Lakeview Pkwy | Fax: (847) 573-1658           | www.objectmentor.com
> Suite 135         |                               | www.XProgramming.com
> Vernon Hills, IL, | Training and Mentoring        | www.junit.org
> 60061             | OO, XP, Java, C++, Python     |

 
 
 

Source Control and Refactoring

Post by Phli » Thu, 03 Jul 2003 07:11:11


Quote:> > Maybe I should write down everything I think I remember about it, and
> > publish that as a book.

> So your argument from authority is really an argument from the memory of
> authority.

Citing an author ain't an "argument from authority".

Try it like this: If you have a .cpp file, and you want to add
#include "screw_in_lightbulb.h" to it, you should not be required to
also add any other file. Syntactically, the .h file should take care
of all identifiers it needs, sometimes via sub-includes. Semantically,
adding the file should be enough to solve one problem. You should not
find yourself needed to add any other .h file just to be able to use
the core abilities of "screw_in_lightbulb.h".

<stdio.h> behaves like this: It provides the FILE abstraction, and all
its "member functions" fopen, fwrite, etc.

--
  Phlip
            http://www.greencheese.org/HatTrick
  --  All analysis and no code makes Jack a dull boy.
      All analysis and no code makes Jack a dull boy.
      All analysis and no code makes Jack a dull boy.  --

 
 
 

Source Control and Refactoring

Post by Paul Sinnet » Fri, 04 Jul 2003 09:50:27



>>> Maybe I should write down everything I think I remember about it, and
>>> publish that as a book.

>> So your argument from authority is really an argument from the memory of
>> authority.

> Citing an author ain't an "argument from authority".

But you weren't citing the author. You were citing what you thought the
author had said:

"One file per package is the recommendation of /Large Scale C++ Software
Design/. Excellent book on physical design issues at all sizes."

And you gave no other justification for this recommendation.

Quote:> Try it like this: If you have a .cpp file, and you want to add
> #include "screw_in_lightbulb.h" to it, you should not be required to
> also add any other file. Syntactically, the .h file should take care
> of all identifiers it needs, sometimes via sub-includes.

You should certainly not be required to include any other header before
including that.

Quote:> Semantically,
> adding the file should be enough to solve one problem. You should not
> find yourself needed to add any other .h file just to be able to use
> the core abilities of "screw_in_lightbulb.h".

You should not expect that include file to give you anything you could ever
need related to that task. The book explains at great length how this kind
of dependency can slow compile time and inhibit re-use.

Quote:> <stdio.h> behaves like this: It provides the FILE abstraction, and all
> its "member functions" fopen, fwrite, etc.

The structure of the C library header files have been broken so long that
they have become a standard for broken header file structure. Here is the
dependency tree for a single #include <cstdio>:

  /usr/include/g++/cstdio
  /usr/include/g++/i486-suse-linux/bits/c++config.h
  /usr/include/g++/i486-suse-linux/bits/os_defines.h
  /usr/include/features.h
  /usr/include/sys/cdefs.h
  /usr/include/gnu/stubs.h
  /usr/include/g++/cstddef
  /usr/lib/gcc-lib/i486-suse-linux/3.3/include/stddef.h
  /usr/include/stdio.h
  /usr/include/bits/types.h
  /usr/include/bits/wordsize.h
  /usr/include/bits/typesizes.h
  /usr/include/libio.h
  /usr/include/_G_config.h
  /usr/include/wchar.h
  /usr/include/bits/wchar.h
  /usr/include/gconv.h
  /usr/lib/gcc-lib/i486-suse-linux/3.3/include/stdarg.h
  /usr/include/bits/stdio_lim.h
  /usr/include/bits/sys_errlist.h

Seems like an awful lot for:

int main( int argc, char* argv[] )
{
        printf( "Hello World!\n" );
        return 0;

Quote:}

 
 
 

Source Control and Refactoring

Post by Ilja Preu » Fri, 04 Jul 2003 16:24:43


Quote:> As far as I know, I'm stuck with:

> 1. DOS Copy file to new 'desired' name
> 2. CVS 'remove' old file (along with local version also)
> 3. CVS 'add' new file
> 4. CVS 'commit' new file

Looks a lot like a batch-script, doesn't it? ;)

Regards, Ilja

 
 
 

Source Control and Refactoring

Post by Tobin Harri » Sun, 06 Jul 2003 10:08:47



Quote:> > As far as I know, I'm stuck with:

> > 1. DOS Copy file to new 'desired' name
> > 2. CVS 'remove' old file (along with local version also)
> > 3. CVS 'add' new file
> > 4. CVS 'commit' new file

> Looks a lot like a batch-script, doesn't it? ;)

Yeah, pretty much. I wrote a VS.NET macro today that does the job nicely
from within the IDEs solution explorer, so I'm pretty pleased with myself!

Tobes

Quote:> Regards, Ilja

 
 
 

Source Control and Refactoring

Post by Darek Ciesla » Tue, 08 Jul 2003 19:35:43


Subject: Re: Source Control and Refactoring
Newsgroups: comp.software.extreme-programming


> Rename the class in the repository, instead.  I wouldn't suggest
giving
> everybody rights to do this, however.

I don't thik that renaming in CVS repository is a good thing. You can
break
project if there are references to source file names in project (the
simplest example is #include "old-filename.h". To be confident that this
change won't break anything you can replace all occurences of
"old-filename.h" to "new-filename.h", but still you'll have problems
with
older versions of source code (won't compile/be executed properly by
interpreter).

I suggest to use CVS "correct" way: mv, cvs rm, cvs add. In order to
make
heavy refactoring I'm using simple script:

        sFrom="$1"
        shift
        sTo="$1"
        shift

        grep -c "$sFrom" -r . |
        awk -v "sFrom=$sFrom" -v "sTo=$sTo" -v sTmpFile=$$
'BEGIN{FS=":"}
        !/CVS/{
                sFile = $1
                sCount = $2
                if(sCount == 0)
                        next

                print "mv " sFile " " sTmpFile

                iPos = index(sFile, sFrom);
                if(iPos != 0)
                {
                        print "cvs remove " sFile
                        gsub(sFrom, sTo, sFile);
                }

                print "sed \"s/" sFrom "/" sTo "/g\" <" sTmpFile " >"
sFile
                if(iPos != 0)
                {
                        print "cvs add " sFile
                }
                print "rm " sTmpFile
        }'

This script replaces all occurences of $1 to $2 including file names.
Typical usage is:

        $ replace OldClassName NewBetterClassName | sh

Of course ALL references to OldClassName will be replaced - even in
documentation (if there is one in my XP projects :). This is safe way -
in
case of errors you can abandon changes in working repository (notice
there's no commit in replace script).

To be sure that such refactoring hasn't broken anything simply execute
test
suite after every replace usage (F9 under my vim IDE - most frequently
used
F-key on my keyboard :).

--
Dariusz Cieslak, tel. 505-670-010, cieslakd (at) wp.pl;
http://cieslakd.prv.pl
C, C++, Java, Python, PHP programmer;          UML, OOA&D, Extreme
Programming

--
Direct access to this group with http://web2news.com
http://web2news.com/?comp.software.extreme-programming

 
 
 

Source Control and Refactoring

Post by Kaz Kylhe » Thu, 10 Jul 2003 08:58:55



> Hi there,

> This is a bit of a silly question, but I'd be interested in comments!...

> In short, does anyone find that the CVS source-control system is a bit of an
> obstacle to renaming classes, when your filenames mirror class names? For my
> team, this is a real pain becuase we like to revist our naming of classes
> often, but then there's the whole drag of having to remove/re-add the
> correcsponding file to CVS!!! Ideally some CVS tool would detect our
> renaming antics and update the repository accordingly.

Meta-CVS supports true renaming, with preservation of history and
merging across renames.

It has a command that can detect external renaming antics, within
certain limitations. That is, if you rename or move files without
using the proper ``mcvs mv'' command, then ``mcvs remap'' will scan
your sandbox and hunt down the moved files by inode number and correct
the map. You then just commit to get the moves into the repository.

 
 
 

Source Control and Refactoring

Post by Ilja Preu » Thu, 10 Jul 2003 16:31:53


Quote:> Meta-CVS supports true renaming, with preservation of history and
> merging across renames.

And then there is SubVersion, a CVS clone which is meant to be able to do
that, too.

Regards, Ilja