Oracle JHeadstart Developer's Guide - Downloads - Oracle

• The files that most often are modified simultaneously by multiple developers are
XML files, which by its structured nature are very well suited for automatic
merging by version control systems. It is our experience that a version control
system like SubVersion is also very good at merging Java files, the other most
used type of file in this development environment.
• When generating your application using JHeadstart, many files are modified
during a generation run. When using the file locking approach, you need to
know upfront which files will be modified by the JHeadstart Application
Generator: all these files need to be checked out prior to generation, otherwise
they remain read only and will not be modified by JHeadstart. It requires in
depth knowledge of JHeadstart and ADF to be able to correctly “predict” which
files will be modified in a specific generation run. With the version merging
approach this is not an issue, once you have finished a development task, the
version control system will tell you which files have been modified and need to
be committed to the version control repository.
2.1.2. Requirements for a GoodVersion Control System
When selecting a version control system, make sure the system provides functionality to
address the following requirements
• It supports the Version Merging model (see previous section).
• It provides a so-called Atomic Commit. With this we mean that when you have
modified a number of files that you want to commit to the version control
repository, you want either the entire transaction to be committed, or the entire
transaction to be rolled backed when a version conflict is detected which cannot
be solved by an automatic merge. In other words, either all files are committed
succesfully, or none of the files are committed. A version control system like CVS
does not support an atomic commit. This means that some files might be
committed to the repository, and then a version conflict is detected and the rest
of the files cannot be committed. When this happens, you end up with an
inconsistent situation in your version control repository since there are many
interdependencies between files in an ADF environment. Obviously, when other
developers update their local copies with this inconsistent set of files, they are
likely to run into all sorts of problems and error messages.
• It detects file changes by comparing file content rather than the timestamp of the
file. This requirement is particularly important when using JHeadstart: when
you regenerate your application using the JHeadstart Application Generator, the
content of many files might remain the same, although the file is recreated with a
new timestamp. When you commit your work after you completed a
development task, you do not want a new version of all these unmodified files to
be committed to the repository. Otherwise, it will be really hard to find back
versions that contained a real change, being a version you might want to revert
to when you want to undo some work.
• An efficient and easy to use user interface to perform common versioning tasks.
Developers should spend as little time as possible with version control tasks. An
intuitive user interface for common tasks like updating their local copy,
commiting changes, reverting to previous versions, resolving merge conflicts,
and creating application releases is essential to meet this requirement. Ideally,
the versioning user interface is integrated with JDeveloper, although in our
experience it is not a big deal to switch with Alt-Tab to a stand-alone GUI for
versioning when JDeveloper integration is not available, or less feature-rich.
JHeadstart Developer's Guide Getting Started 2 - 3