Wednesday, September 12, 2012

Tips for Working with VCP projects & SVN

Now, before everyone gets all agog, I'm NOT an SVN expert BUT I am quite familiar with how to use it in conjunction with Real Studio & VCP files.

Most of this experience comes from having worked for Real Software for the last 4 years and dealing with SVN on OS X, Windows & Linux. We use all three here and there are a very minor number of issues that we run into. If you have a team also using SVN then you're likely to experience them as well.

First things first - use VCP with SVN :)

Yes, you can use XML, but XML files are much harder to merge and compare differences because they are XML. We do use some binary files, mostly images, and there's not a lot you can do to practically compare two binary files. It would be nice, but SVN doesn't do that. Now IF you happen to use a LOT of external files, which has pros and cons in a team environment especially if you're doing work for many clients, you may have to use either XML or RBP files. There's no way around that at the moment. That's one of the issues with external items.

The other issue is that if you use some common code you might be better off being able to "clone" it to client projects on a predictable schedule that you control, instead of just whenever it's updated in another project. And SVN does make this possible if you use subprojects or relative locations. (see This allows you to keep your "common code" up to date in one place and then YOU decide when to update it to other projects you use it in.

With SVN in a team environment one of the things you definitely want to avoid is nuking another developer's changes. As long as you regularly update from the repository, this is not hard to avoid and most are easy to deal with. And always update BEFORE committing your changes just to make sure you're not about to put some code back in your main repository that has conflicts. Conflicts arise when you and another team member happen to change the same line in a file. When you update, most SVN clients will highlight the difficulty and let you know. When it's in code, it's not a problem and the IDE will open the items and you can find conflicts by running an analyze, and the IDE will highlight the conflict markup as invalid syntax.

The hardest conflict to deal with is when you add something to the project and someone else does as well in their working copy. In a VCP project, adding an item modifies the "manifest", the file with the RBVCP extension, that represents the items in your project. A conflict in this file will make it so your project won't open any more as the IDE has no clue what this conflict markup code means.

So what does a conflict look like and better yet, how do you fix it ?

The first thing to know is the RBVCP file is just a text file so you can open it with TextEdit, NotePad or any other text file editor (emacs, vi, vim, or pico for those who are so inclined).
Often a conflict will look like:

<<<<<<< .mine 
Folder=Autocomp Stuff;Autocomp Stuff;&hBC57A158;&h0;false 
Folder=RB Language Support;RB Language Support;&hBC57A148;&h0;false
>>>>>>> .r6
which says that in MY local copy of the RBVCP file I added a Folder (hence the Folder=) and that in the repository that line has a different folder - someone else added that and checked their change in before mine.

In this case I want to keep both things, otherwise I'd drop the other person's new folder from the project. You'd edit the RBVCP file and make sure both lines are in the file. Then mark the conflict as "resolved" - how you do this varies from SVN client to SVN client - and commit that change.


Oliver Osswald said...

<> -
You probably could work around this problem, maybe like this: instead of keeping a list of items inside of the rbvcp file, create a folder which acts like a database. Inside of the folder write a file for each item (similiar to a record in a database). - When a developer adds or removes an item to the project, Real Studio creates or removes an entry (a file) inside that folder. The rbvcp file points to the folder and does not change. It still can serve to load the project. -
Like this we probably would not overwrite the manifest, the rbvcp file, to eachother.

Norman Palardy said...

That might not make the problem simpler but harder since for every item you add or remove to the project you'd have to do an svn add or remove.