can I have svn for RFT scripts?

We user svn at work and now we are introducing RFT (Rational Functional Tester).

Is there any chance I can use existing svn to version my RFT scripts? I understood that one RFT script contains is not equal only one file.

• RFT v 8.1.1.2 runs on windows xp
• svn runs on linux

• is it good enough to versi开发者_如何学Con .class and .java files?

You can use Subversion to version any file. However, text and binary files are treated differently. For text files it is possible to view differences line by line, with binary files you can simply check out an older version.

Yes, you can use SVN. But DO NOT version .class files, as they're compiled java files and can change between builds. It's better to rebuild the project from Eclipse every time you do an update.

Beware that some RFT files cannot be merged (like datapools .rftdp) because they are XML files written in one unique line, so you have to lock those files if you need to edit them or sync with your team or you can resolve conflicts accepting the last committed revision.

We have been succcessful using RFT with SVN. However, we had to use file locking because there are a number of files (XML) that are used to make up an RFT script. We added the subclipse plugin to RFT. We then create an empty RFT project with the same name as the project that we imported to SVN. We then check out the RFT Project from SVN on top of (Overwrite) the empty RFT project. When we create a new script, we add the svn:needs-lock property to the java file. When we do updates and commits, we select the project this results in the other resource files associated with the script to be included in the commit.

Install VMware Ubuntu on the Windows XP developer boxes and run linux on it.

We did exactly that in our previous organization. All the developers had VMware Ubuntu installed on our Windows machines. You can can Eclipse or MyEclipse or RFT from there, version the RFT code from the IDE or from command prompt.

I'll somewhat repeat the other answers, but I hope to clarify it more.

First problem: Object Map files. These are simple XMLs files. They could easily be tracked to version control, unfortunately IBM did a mess here. They don't use a good parse library for the XML. It must be contained in just one line. If you tidify the code, it won't be parsed any more. Since the version control software tracks line differences, every simple change will create a mess of a conflict.

Even if it worked after reformatting to multiple lines, each little modification (e.g., add a new test object) would reorder all the xml contents. Sure, I tried it all.

In practice, the object map files are binary files and you must add the svn:lock property to each of them. They used XML just as a buzzword, intentionally preventing all the format advantages.

Second problem: RFT generates a lot of helper files from your object maps. These are the files in the "resources" directory. Against version control good practices, you must also manually commit these files. Be shure to commit everything that changes.

RFT has ClearCase integration, and it automatically checkout and checkin all the needed files. But don't get into this integration from Hell. You'd be better with Subversion.

Conclusion: If you use RFT, you are doomed to have sequential development. You can't have 2 developers working in the same codebase. Welcome to the 70's!