Sunday, June 01, 2008

Using Subversion in SQL Developer... Easy?

I find doing database development with Subversion a challenge. Maybe I'm not using it correctly, but at the moment I don't like the way it's working in SQL Developer.

For an APEX developer, SQL Developer is a real blessing, especially when you're on a Mac like me and there are not that many choices in this kind of software. The integration with Oracle Application Express is really nice, but that's probably worth another post.

Why would you use Subversion? If you're with more people on the same project, how do you control who's changing what? In Apex you can lock a page you're working on, but how about PL/SQL packages? Subversion can help you to keep versions of the code and have a control of who changed what and when.

I wanted to blog about the way I'm working with Subversion and really wonder if there's not a better way of doing things.

To start, what you need is a Subversion repository where you can connect to.
The connection wizard is working well. A screenshot of the Versioning Navigator, the Subversion tree and the properties of my subversion connection:


If everything is working you'll get a tree of directories and files which you can navigate.

So I've access to my repository of files. Let's start coding...

You can view the files by clicking on it in the tree of Versioning Navigator, but you can't edit them. You first need to check them out to a local directory and then Open your local files. I was really surprised you can't check out a file, you need to check out the entire directory! Once you know it, you get used to it and maybe it isn't that bad anyway.
It would have been nice if I double clicked on the repository, that it would give me the option to load the local copy, but that's not the case, you need to do it the hard way and open it by searching for it yourself in your local copy.

Once your local file is open, you've some possibilities like Lock, Update, Commit etc. the typical things I would say. First I do an update as I want to be sure I've the latest version.
A nice thing about Subversion is that it can merge files/changes. So when somebody else changed something while I was also changing it, after doing an update both changes got merged.

I'm changing my loaded package from my local file system and want to compile it into the database, but that's another difficulty with the current implementation in SQL Developer. You can compile your package, but the log window is not available, so you don't know if you've errors or not. That's very annoying... So you need to go to another window in SQL Dev to compile it properly.

When I'm happy with the changes in my package I update again and finally do a commit in Subversion.

The flow is not "flowing" enough for me...

Following changes in the implementation would help me:

  • Get a visual indicator that somebody is working on a file from the subversion tree or in the database tree itself.
  • Be able to do a compile and see the log window
  • When double clicking on a package in the database or in the versioning tree have the option to load the local copy (linked to subversion). Automatically an Update is done, so I'm sure I'm working on the latest version.

How do you work with Subversion? Do you have some tips and tricks for me?

6 comments:

Anonymous said...

yes it is pretty easy, i dont see your problem?

Anonymous said...

u shd not show ur username in da screenshot

Anonymous said...

rby is grate for subervison


http://www.rubyonrails.org/

Anonymous said...

For what it is worth i agree with you . . . that said your post allowed me to even figure out *how* to use it such as it is. Surprised they didn't fix the need to open your local copy in v2.1 . . .

Mike said...

Dimitri,
Are you still using Subversion alongside SQL Developer? We're looking at using Subversion at the moment, we have both Toad and SQL developer users so just want to make sure we're making the right choice.

Thanks,

Mike

Dimitri Gielis said...

Sure we still use Subversion.

But you should decide yourself what you prefer to work with. If you find something else better or easier to use in your team, go with that.

It's like with code, always test in your environment first and verify it's what you need ;-)