Thanks to Oracle's Susan Duncan at the ODTUG conference, I was reminded today why Subversion is the file version control of choice over CVS for JDeveloper. One of the main advantages is atomic commits.
As many JDeveloper developers will be aware, on making changes to something like an ADF Entity Object (EO) property via a wizard within an ADF project, a change may in fact result in modification of several files behind the scenes. When the developer decides to commit their changes to the file version control repository, the tool must submit all the files that changed for the ADF Entity Object to the repository for other developers to use.
However imagine the scenario where during the commit/submit of say 4 files representing the one ADF EO, the operation is successful for the first 2 files, but fails for the 3rd and 4th. We now have code within our repository that is inconsistent, some representing the earlier version of the EO, and other files representing our new version. This is going to cause major headaches for other developers who download the latest code changes from the repository, and get a mix of new and old files representing the one EO. In particular JDeveloper will probably not be able to handle this situation as there will be inconsistencies between the files. I must note this scenario is not particular to just JDeveloper, it can be an issue for all sorts of environments and is a common file version control system issue.
Unfortunately this issue is a real problem for CVS, but CVS's successor Subversion solves this through the use of atomic commits.
An atomic commit ensures that on a commit/submit, all the files are committed on success, or on any failure, all the changes are rolled back. With this feature we can guarantee the success of the overall action, or the complete failure, not some combination there of.
Thus this is why Subversion is a common recommendation for JDeveloper sites over CVS, and JDeveloper adopters should heavily consider picking Subversion for this reason.
To be clear, readers should not discount *other* file version control systems besides CVS and Subversion. You should in fact check if your tool of choice supports atomic commits among other features. From a quick Google I discovered there is a great site Better SCM that describes and compares the features of many file version control systems available, including atomic commits.
4 comments:
Chris,
This is one of my long-running crusades as well. For this very reason, I would never use CVS (again) on an ADF project (I've tried in the past, and been bitten by it).
Ehm, you should use subversion instead of CVS because the developers have already said that CVS development is stopped and everyone should jump into the SVN wagon.
AFAIK :)
BTW You should look into git, subversion is already outdated for most developers...
While I understand your point about git, I don't believe there is yet a plug-in for JDev supporting git (I may be wrong), and your comment "most" developers is overstating the fact from my own subjective experience.
CM.
Post a Comment