Upgraded to Subversion 1.7

If I am asked why you don't like SVN, the evil .svn folders is the answer. With the newly introduced Centralized Metadata Storage, there is only one .svn directory for each project, just like the .git folder in Git repository. Is it time to re-love Subversion? Well, yes and no.

In order to support this new feature, you have to install Eclipse Subclipse plugin 1.8.x. But before that, it's better do a

svn cleanup

for all of your working copies. Although I didn't do it and so far so good, don't risk it.

If you followed this tutorial and installed libsvn-java, please uninstall it. Because at the time of writing, the version of libsvn-java in Ubuntu repository is 1.6.12. When you try to access SVN server, you'll get

Incompatible JavaHL library loaded. 1.7.x or later required.

Follow this to install libsvn-java 1.7.0 and upgrade your working copies with

snv upgrade

Now you have a centralized .svn folder. But don't think you can operate directories and files freely from now on. I use Subclipse 1.8.2 on Eclipse 3.7 SR 1 on Ubuntu 11.10 and found if you delete files and folders directly from file system, the deleted files and folders wouldn't show up in Synchronize view. However, if you add new files and folders, or modify files directly in file system, the plugin will get all the changes.

Even if you delete a folder from Eclipse, and copy a folder with same name but with some changed files, you may get

Could not remove /home/jerry/java/workspace/...

It looks like the metadata fails keeping integrity. I suggest you keep all the folder structure and remove all the files in a folder tree in Eclipse, and copy a whole folder tree with files into project later. Although you may still have following errors, after you refresh project, everything should be fine.

Errors occurred while updating the change sets for SVNStatusSubscriber
org.apache.subversion.javahl.ClientException: SQLite error
svn: database table is locked
svn: database table is locked: WORK_QUEUE

Errors have occurred while calculating the synchronization state for SVNStatusSubscriber.
org.apache.subversion.javahl.ClientException: SQLite error
svn: database table is locked
svn: database table is locked: WC_LOCK

org.apache.subversion.javahl.ClientException: SQLite error
svn: database table is locked
svn: database table is locked: NODES

I summarize my suggestions:

• always delete files from IDE;
• if files changed but folder structure remain the same, don't delete folders from IDE

Funny statements regarding Database and ORM

Twitter is great to share things that's hard to misunderstand. 140 characters are just inadequate to explain your philosophy of software development, even a series of tweets. Is a meaningful tweet to you also meaningful to your thousands of followers?

I saw a series tweets from Uncle Bob Martin today and found them very confusing to me, and maybe misleading to others.

Databases are details to be hidden. They are not your central abstraction, nor are they the core of your application. Ever.

In any multi-tier software architecture, lower tier provides service to the tier that sits on it. Upper tier defines the contract for lower tier to implement, rather than vice versa. Databases, as a repository service, is by no means a central abstraction, or the core of the whole application. Otherwise, my garage is the core of my house because I store everything there.

But, databases provide an abstraction (no central here) to the tier just above the database layer. As long as the JDBC URL (from a Java developer's perspective, luckily Java is still popular in enterprise software development) is not used outside data access layer, we can say databases are hidden.

Personally, I really don't know how not to make databases hidden, how not to think databases are not central abstraction, or not the core of an application.

relational tables hold data structures, not objects. Objects are bags of behavior. Data structures are bags of data.

I think he wanted to express either relational tables hold data structures, not classes; or relational tables hold structured data, not objects. But anyway. Relational tables don't hold objects / classes is just the reason why we need ORM to map them to objects / classes, and operate hidden data though interfaces.

Any bridge is used to connect two different entities. ORM is the bridge between data and objects, or tables and classes. If the mapped objects don't provide something else convenient to application development, why do we do the mapping? From a bags of data to another bags of data? Yes, we can. But only in mapping to something like C.

The O in ORM is in error. It should be DS for Data Structure. No simple tool can map tables to objects.

Here comes the funniest part. Everyone knows ORM is first introduced in Java. That's easy to understand why ORM has a O in it. Java doesn't have struct keyword, so it's ridiculous to criticize the naming of ORM. Can't we teach Data Structure in Java? The getters and setters in mapped objects are not behavior?

Unless you apply Domain Driven Development, there are no operations other than getters and setters in mapped objects. Even if you apply DDD, the operations in mapped objects are not mapped from table, they come from business rules. For example, what, in a User table, can be mapped to a addUser() behavior in User class? Don't tell me it's mapped from a stored procedure called add_user. We're talking about tables, right? Stored procedures live inside database, but outside any tables.

If anyone really likes this kind of naming game, here is a free topic for you if you have thousands of followers like this guy. The disk in RAM disk is in error.

Have fun.