Craig Schumann on Source Control - Part Two
In Part One of this three-part interview, Craig discussed what you really get in Domino 8.5.3, whether this is enough for a typical Notes environment, and why you should have a source control method in place.
Below, he explains how DXL plays a major role in Domino's source control enablement feature (included in 8.5.3), and how that can impact source control methods. He also provides some guidance on which source control method could be right for your organization. Read on!
What are the most important
things to consider when determining what type of source control is needed?
It’s important to know that all of
the new source control enablement features in Domino are based on DXL.
For those who don't know, DXL is just an XML
representation of a Domino document or design element. There have been
a lot of improvements to DXL over the past few releases, but there are
still issues with how things, especially rich text fields and form body
elements, are exported. (Keep in mind that XPages are already stored as
XML in a database, so this issue does not affect them). The upshot of this
is that the element’s DXL representation isn’t the same as the way it
was stored in the database. This might not be a showstopper for a lot of
people, but it’s a huge issue for highly regulated industries where version
control, change control, and accountability must be maintained at all stages
of development. You can talk to anyone in the finance or medical industries
about that!
But this doesn’t just affect management
and auditors. It poses a major problem to any developer trying to implement
a source control system, because it means an element cannot be rolled back
to a previous version. This is the round trip or full fidelity problem.
One of the more important features of
any source code control system is the ability to roll back to a previous
version of a resource. The issue with DXL is that when you export something
small, omissions in the design of the element will be silently stripped
out if the exporter doesn’t understand them. Later, when you try and re-import
them, even more things may be omitted. To make things even more complicated,
this all assumes that the version of Notes that you used to export and
import are the same. But if they are not, even more problems can be introduced.
This makes it problematic to reliably roll back to any design element,
especially if the version of Notes has changed since the element was checked
in. IBM, to its credit, does offer an option to work around this deficiency
by exporting the design elements in a binary format. This addresses the
problem, because the DXL exporter and importer does not have to understand
the XML structure; all it does is convert the binary data back into a binary
field on the design element, so you don’t lose anything. Unfortunately,
though, this poses a problem for a source control system. When you are
reviewing changes between checkins, you very often need to do a diff of
the 2 versions. But storing the design of a form in a binary format makes
this impossible, since the diff tool can’t understand the data.
Along with all of this, you will also
need to decide the kind of SCC tool you want to use. As I alluded to above,
SCC tools are are basically broken down in to two types of workflow.
The most traditional is a locking type
with a check out/edit/check in method. This is the way most source control
tools like Subversion work. A user checks out a resource, makes a change,
then checks it in. Until the user checks the resource back in, other developers
can’t make changes to it.
The second is a distributed method with
an edit/merge/commit style of working. Distributed tools, like Mercurial
and Git, are all the rage right now, but I think they have a slightly steeper
learning curve for people new to the source control world.
The way distributed tools work is that
you can edit any resource as much as you want, because you are only changing
your copy of it. When you are ready, you merge your changes with the changes
that other developers may have made, then commit your changes to the main
repository. The key difference here is the merge. Distributed systems do
not prevent other developers from changing the same elements. It’s
up to the developer to sort out any conflicting changes before anything
can be submitted. Depending on the size of the project, or the number of
developers working on something, this can get pretty tricky, and it’s
the reason why I don’t usually recommend these tools for Domino development.
Unless you spend a lot of time in the source pane when you do XPages development,
the merge might be the first time you actually see the source code for
your XPages, and this is a bad time to learn how to read XML. Most of the
XML diff tools are really good these days, but no matter how good they
are, it doesn’t make any of the decisions for you, so you really have
to know what you are looking at. Certainly, if you are the only developer
working on database, you won’t ever run into this problem - but that would
defeat the purpose of this type of tool, since the term “distributed”
doesn’t really apply in the first place.
This is why I think the more traditional
approach of check out/check in works best. It’s a little more cumbersome
to work with, since it requires a higher level of communication within
the team, but it also enables you to avoid the merge problem.
We welcome your comments and feedback on
Craig's insights above. And look out for the conclusion to this interview
(coming soon) in which Craig shares the source control methods we've developed
and use here at Teamstudio.
O Category :
|
Permalink
| Comments (0)
|
|
|
|
|
