As you work with modules managed in source control, differences
arise between the local and remote copies of the modules. To keep
the artifacts in the local working copy and remote source control
system in accordance with one another, the local workspace should
be synchronized with the remote software configuration
management system (SCM).
Before you begin
This topic applies to software configuration management systems other than IBM® Process Center, which has more integrated processes than the ones described here. Actions and terminology may vary from one SCM system to another.
About this task
Use the Team Synchronizing perspective to synchronize
the local and remote copies and to identify artifacts that need to
be committed or updated. Synchronize often to check for updates from
other users. Synchronizing is especially important for core artifacts
that may be used in multiple modules, such as libraries with WSDL
and XSD files.
If you try to commit items that have been modified
by other users, you will see a merge conflict. Although there are
merge tools within the Team Synchronizing perspective, these tools
are designed for traditional code such as Java™ and do not work well for XML-based business
process artifacts. Merge conflicts should be handled manually.
You
can only use the commit operation for modules that are already managed
in source control. If you are creating a new module, use the Share
Project window.
Procedure
To synchronize the workspace module with the remote repository:
- In the Business Integration view, right-click the module
name and select .
- Click Yes to open the Team Synchronizing
perspective.
A list of modified artifacts will appear
in the Synchronize view.
- Optional: Use filters to reduce the list of modified artifacts
that appears in the Synchronize view.
By default, all changes
and conflicts appear in the synchronization list. You can change the
filter to show only outgoing changes, incoming changes, or conflicts.
- Commit, update, or merge conflicts through the Synchronize
view. You can commit all the changes or individual changes. Right-click
the module or artifact to make these changes.
In CVS, a
dirty flag (>) in your workspace indicates that your local copy differs
from the copy in the software configuration management system. If
no differences are listed, no commits or updates are needed. Although
you can update or commit before synchronization, that is not a recommended
practice. The synchronization wizard shows you a full list of changes
that have been made in the local and remote module versions. If you
commit or update these changes without synchronization, then you might
overwrite critical work from other users. Avoid these problems by
always synchronizing first. Furthermore, when you are working with
modules that may see frequent revisions, synchronize often to verify
that your local working copy is current.
- To commit your work to the software configuration management
system, right-click either the module or artifact name and click Commit.
You need to save any changes that you made in the local working
copy to the remote repository before the changes take effect. When
you add a project to the software configuration management system,
an initial commit action saves all artifacts from the local working
copy to the repository.
- To update your local working copy, right-click either
the module or artifact name and click Update.
If other users have made changes to a module that you have checked
out, your local working copy is out of sync and needs to be updated.
An update is effectively the polar opposite of commit-instead of pushing
changes from the local workspace to the source control system, an
update loads any changes from the source control system that have
occurred from the time the module was checked out.
- Merge conflicts.
There are a few options
you have when merging conflicts. For traditional source code, such
as Java, the best and easiest
option is to use the merge utility to assist with integration from
both versions of the code. However, this is not quite practical for
artifacts that you developed in the Integration Designer, because
they are XML-based and are usually very difficult to integrate in
raw-text format. Most often these artifacts are developed using GUI
tools, so performing text-based integration is risky and error-prone.
If a core artifact is improperly merged, the process needed to rectify
problems can be very time consuming and may adversely affect other
artifacts or modules. If you absolutely need to merge Integration
Developer artifacts due to conflict, make sure you keep local copies
of both artifacts in case you need to revert to one or the other.
If at all possible, try to avoid merge conflicts altogether. If you
know that multiple users will be working with a common module or library,
discuss this matter with your team and make certain that only one
person will make changes to an artifact at any given time. You can
also use the Lock and Unlock options in the Team menu to lock read
or write access to specific modules or artifacts.
- To prevent multiple users from having write-access to
a module or resource, set a lock on it. From the Business Integration
view, right-click the module and select . Select Lock
recursively and click OK.
The module is now locked for your exclusive use. You will see
pink lock icons in your workspace. When a module or artifact is locked,
other users can still check out the module, but they will not be able
to commit any changes until after the lock is released. When you no
longer need exclusive access, make sure you unlock the module.
- To mark the file as merged, right-click a module or
artifact from the Synchronize view and select Mark as Merged.
The Mark as Merged option allows you to override the conflict
markers by marking the artifact as if it is already merged. Use this
option when you have manually merged the artifact in question and
do not want to use the text-based compare-and-merge utility to merge
conflicts. The merge-conflict indicator will be removed and the artifact
can now be committed or updated, accordingly. Locking only affects
write-access to an artifact. If a module is locked by one user, other
users can still check out a locked module, but they will not be allowed
to commit any changes until the lock is released.
This topic only applies to BAW, and is located in the BAW repository. Last updated on 2025-03-13 12:15