Workaround When Eclipse Fucks Off With CVS

Until recently, I always found Eclipse CVS support to be excellent. The synchronize view was really a big plus to do clean commits, without forgetting any file.

But I have encountered several problem with Eclipse 3.2+:

On one project, it keeps putting the build directory into CVS, and I can't find how to change that setting. Each time I open the project I have to change the CVS/Entries file.

On another, where I have lots of files in, Eclipse delete some of the files (checked in CVS) regularly, although not often. It won't retrieve them back again from CVS. It seems to be the same files each time. I have no clue why.

The diff sometimes tells me the whole file has changed while there is absolutely no change.

I could not make the merge work. It kept on complaining about some parameters.

And now the workaround for all those cases:

The good old CVS command line.

I never remember how do to a merge with the command line, so I each time go to google and read this merge example page. Here are the very simple steps if you are in a branch and want to merge:

1. cvs update -A mypoem.txt (use head as local repository)

2. cvs update -j release-1 (merge release-1 changes into local repository)

3. cvs update mypoem.txt

4. cvs commit mypoem.txt

Workaround When Eclipse Fucks Off With CVS

Until recently, I always found Eclipse CVS support to be excellent. The synchronize view was really a big plus to do clean commits, without forgetting any file.

But I have encountered several problem with Eclipse 3.2+:

On one project, it keeps putting the build directory into CVS, and I can't find how to change that setting. Each time I open the project I have to change the CVS/Entries file.

On another, where I have lots of files in, Eclipse delete some of the files (checked in CVS) regularly, although not often. It won't retrieve them back again from CVS. It seems to be the same files each time. I have no clue why.

The diff sometimes tells me the whole file has changed while there is absolutely no change.

I could not make the merge work. It kept on complaining about some parameters.

And now the workaround for all those cases:

The good old CVS command line.

I never remember how do to a merge with the command line, so I each time go to google and read this merge example page. Here are the very simple steps if you are in a branch and want to merge:

1. cvs update -A mypoem.txt (use head as local repository)

2. cvs update -j release-1 (merge release-1 changes into local repository)

3. cvs update mypoem.txt

4. cvs commit mypoem.txt

Maven: Game Over, Try Again

I am writing only as a newbie on Maven2. I tried to use it several times on small projects, but each time I found out that the time involved to make it work with an existing project was too much a pain in the a**. When confronted to very simple hierarchies that are not the standard of the documentation, I was a bit lost on how to arrange things, except changing the whole hierarchy to adapt to Maven.

Also on small scale code, Maven requires you again to adapt your project to it and it will make your small code look like an important enterprise project. For example if you want to build a small test that can be executed as a server (with one particular class), as a client (with another class), or as a servlet, using one or two other common classes, Maven requires at least 3 source hierarchies (with src directory).

I think it is not only because I know ant (much) better that ant proved many times to be quite flexible, and I have never been on a project where switching from Makefile to ant was a problem. I am not an ant fan. I have a preference of code over XML that ends up here and there being like code, in a much less flexible way. However Ant, as I said, is flexible. One can always use the good old scripting languages (javascript, beanshell, etc.) to define new tasks, and therefore bypass any inflexibility of the original design.

Still Maven2 has plenty of very good stuff, especially for more normal projects. It provides versioning, central repository and dependency checking for you. It is probably a good idea to use it rather than bad ant scripts, or, even worse, old Makefiles. Also Maven2 hierarchy conventions are not stupid, it is just not fitted for quick and dirty stuff.

Maven: Game Over, Try Again

I am writing only as a newbie on Maven2. I tried to use it several times on small projects, but each time I found out that the time involved to make it work with an existing project was too much a pain in the a**. When confronted to very simple hierarchies that are not the standard of the documentation, I was a bit lost on how to arrange things, except changing the whole hierarchy to adapt to Maven.

Also on small scale code, Maven requires you again to adapt your project to it and it will make your small code look like an important enterprise project. For example if you want to build a small test that can be executed as a server (with one particular class), as a client (with another class), or as a servlet, using one or two other common classes, Maven requires at least 3 source hierarchies (with src directory).

I think it is not only because I know ant (much) better that ant proved many times to be quite flexible, and I have never been on a project where switching from Makefile to ant was a problem. I am not an ant fan. I have a preference of code over XML that ends up here and there being like code, in a much less flexible way. However Ant, as I said, is flexible. One can always use the good old scripting languages (javascript, beanshell, etc.) to define new tasks, and therefore bypass any inflexibility of the original design.

Still Maven2 has plenty of very good stuff, especially for more normal projects. It provides versioning, central repository and dependency checking for you. It is probably a good idea to use it rather than bad ant scripts, or, even worse, old Makefiles. Also Maven2 hierarchy conventions are not stupid, it is just not fitted for quick and dirty stuff.