Ans. WANdisco's unique active-active replication technology is its key advantage. Unlike competing multi-site solutions, WANdisco doesn't rely on a central transaction coordinator that can easily become a single-point-of-failure. Instead, WANdisco is installed with each development site's Subversion or CVS source code repository replica. Each source code repository replica then becomes an active node on the WAN with its own distributed coordination engine (DConE™). These DConEs accept local updates and propagate them to all of the other repository replicas in real-time. Everyone is effectively working from the same copy of the source code repository regardless of location. This means that development procedures don't have to change when development moves offshore. Developers don't sit idle waiting for large builds to complete when work from multiple sites is integrated to meet project milestones. Problems are detected earlier. Less time is spent in QA.
Ans. Other multi-site solutions that lack WANdisco's real-time capabilities have a fundamental problem in that they can never guarantee that local and remote repositories will be in sync at any point in time. This means that there is a great likelihood that developers at different sites could easily clobber each other's work. To prevent this, these solutions require excessive, error prone source code branching and file merging to become part of the development process. This effectively forces development work to be partitioned based on geography, and makes collaboration between distributed development teams virtually impossible. As a result, problems are not discovered until later in the development cycle resulting in more QA and rework.
In addition, multi-site solutions that rely on master/slave architectures force developers to check out source code from the local repository, and check in their changes to the master. This often leads to inadvertent source code merging and check-in snafus. With WANdisco, developers check out from the same source code repository that they check in to, avoiding these issues.
Ans. WANdisco does not operate on the principle of master and slave repositories. WANdisco operates on the principle of one-copy equivalence across all of the source code repository replicas. This means that every repository replica is always in sync with every other, so developers at every site are always working from the same code base. All of the repository replicas are in effect peers.
Ans. Yes. Each developer's changes will be reflected as different revision numbers in all of the distributed source code repository replicas. There is no need to create separate source code branches with WANdisco. This same behavior would occur if the developers were working together at the same site against the same repository over the LAN.
Ans. Let's assume two developers at two different sites checkout the same file and make changes to the same line. The first developer commits their changes and a revision number is assigned. The changes just committed by this developer are already in the source code repository replica at the second developer's site because WANdisco immediately replicated them.
The second developer was unaware of this latest revision and failed to do an update. The second developer then attempts to do their commit and receives an out of date error message, just as they would if both developers were working against the same Subversion or CVS repository at the same site. Users will even see the same Subversion or CVS messages.
The second developer whose commit failed can then do an update from their local repository and they will pick up the latest revision. As soon as this developer resolves the conflicts their changes are committed with a new revision number, and propagated to all of the other repository replicas.
Ans. When network or server failures occur, developers can continue working. When connectivity is restored, the local replicator will reach out to replicators at the other sites to bring the local repository up to date. Recovery will happen automatically, without any intervention from an administrator. This ensures zero loss of data.
Ans. The first advantage is that WANdisco's quorum approach increases availability by ensuring that transactions can still be committed as long as a quorum of the development sites are up. The second advantage is that it ensures that repositories do not go out of sync even when the network partitions.
WANdisco also employs the concept of a distinguished node, or singleton quorum. For scenarios where there is an even number of WANdisco development sites (nodes), the distinguished node can act as a tie-breaker, so that transactions can still be committed.
Ans. If a site experiences a network outage, users at that site will still have read access to their repository. Each of the remaining sites will continue to have full read and write access to their repositories as long as a quorum of sites remains available. As soon as the site experiencing the outage comes back online, it will catch up automatically with all of the write transactions that took place at the quorum sites during the outage. No administrator intervention is required for recovery.
Ans. This option allows the distinguished node or quorum to be configured to rotate to another site or group of sites to optimize performance during their normal working hours. For example, if a server in Bangalore, India needs to be kept in sync with a server in San Jose, California, WANdisco can be configured so that during each site's normal working hours, that site can become the distinguished node, and write steps incur no WAN latency. During Bangalore's normal workday, updates are still propagated to San Jose; however they now occur in the background asynchronously. After the workday ends in Bangalore, the distinguished node will rotate to the San Jose site, and San Jose's writes will incur no WAN latency, as changes from San Jose are then propagated asynchronously to Bangalore.
Ans. Three ways:
Ans. No. No. WANdisco doesn't require any changes to SCM client configurations and it doesn't touch the SCM server file system. WANdisco is effectively a transparent network proxy between the client and each site's local Subversion or CVS server. WANdisco can be installed on the same server as Subversion, the Apache web server used to front-end Subversion, or the CVS server. Developers won't even notice that WANdisco has been implemented. Clients still connect using the same ports they always have. The only difference is that they are actually connecting to WANdisco's proxy (replicator) instead of directly to their Subversion or CVS server. In the case of CVS, clients still connect using standard pServer port 2401 or SSH. For Subversion standalone, port 3690 is used. For Subversion with Apache port 80 is used for HTTP, or port 443 for HTTPS. If ports other than these defaults are used, they can still be used after WANdisco is implemented.
Ans. Agile's primary objective is frequent delivery of working code. Agile development is iterative and incremental. It requires continuous build-test-deploy cycles and continuous communication. The biggest challenges in distributed environments lie in maintaining the same levels of communication and continuous build integration that's possible with everyone in the same location.
Central server or master-slave server solutions like svnsync or rsync can't address these requirements in large distributed development organizations because:
With either Subversion MultiSite or CVS MultiSite, repositories are fully readable and writeable at every location and continuously in sync. The latest changes are always available everywhere and everything happens at local area network speed. Merge conflicts and other problems are caught and fixed when they occur. Each site can perform builds and test locally with the latest code, regardless of where it originates. Delays caused by broken builds and scheduling challenges with a central build team go away.
Both Subversion Clustering and CVS Clustering allow build processes to be offloaded from the server used by the developers, improving their productivity. At the same time, the latest changes from the development team's server are available on the other servers in the cluster where continuous builds are running.
Ans. WANdisco's Subversion Access Control and CVS Access Control solutions provide full authorization, authentication, access control and audit capabilities that go well beyond what Subversion and CVS provide on their own. Administrators can implement and maintain the most complex security policies across all development sites with minimal effort. User definitions can be imported in bulk from LDAP, or other authentication servers to avoid manual entry. Groups, roles and users can be defined and fine grained access control can be implemented down to the branch, module, source code file, or client ip address levels. ACLs defined at the group level are inherited by all of the users in the group. It is also possible to further restrict access for individual group members. Once the security configuration is defined it can be replicated automatically to all sites when used in conjunction with WANdisco's multi-site solutions.
Online audit reports that show access history for each user, as well as any access violations are provided. Audit alerts can be configured, and audit log SQL search functions are also provided. Checkin/checkout history is tracked and can be fed into project management systems to map task completion against plan.
Ans. WANdisco uses the same user ids as the underlying Subversion or CVS repository. When WANdisco's access control solutions described above are implemented, additional user information is included with the user id to support audit reporting and email alert capabilities. These additional items include the first and last name of the user, their email address, and group membership.
Ans. Most customers set up a VPN using an IPSec tunnel. SSH tunneling can also be used. In addition, WANdisco's DConENet protocol which runs on top of TCP does its own binary encoding on the WAN to further obfuscate any data transmissions between replicators.
Ans. Yes this is possible. WANdisco can be configured to replicate only specific SVNROOTs or CVSROOTs.
Ans. Yes. WANdisco provides tools for CVS and CVSNT (fast-cvsroot-diff) and Subversion (fast-svn-diff) that are available for download from the support site. These tools will show the files that are different between repository replicas. These tools are also optimized for WAN performance, so that gigabytes of data can be compared in minutes over even a slow WAN link. The user can take a snapshot of the state of their repositories across all of their development sites, and obtain a report identifying any files that are different between their repositories.
The WANdisco replicator also has an internal mechanism that allows it to automatically detect any out of sync files between the repositories. This protection is always on when the WANdisco replicators are running. This will also catch operational errors, such as permissions not being the same at all the sites, accidental deletion of RCS v files in the case of CVS, or disk corruption at any of the sites. If an out of sync condition is detected, the replicators go into read-only mode. Email and audit log alerts are generated and displayed on the administration console.
Ans. Yes. This is supported leveraging the self-healing features offered by WANdisco. For example, the network connection can be disabled between the distinguished node site and the other sites on a periodic basis (e.g., twice a day). When the network is reconnected, the remote replicator will reach out to the distinguished node to pick up all of the commits that were done at the distinguished node site during the network outage.
Ans. Yes, WANdisco is considered suitable for hosting on perimeter networks that may be open to external access. Customers who deploy in this manner use standard procedures for Apache server hardening and may perform routine scans for server vulnerability. WANdisco currently supports Secure Sockets Layer (SSL) encryption for improved security.
Ans. WANdisco recommends allocating enough disk space for its transaction journal to allow for seven days of write activity against the repository.
Server Versions Supported:
Subversion server versions 1.3 and above are supported.
FSFS and BerkeleyDB are supported.
Subversion command line, SmartSVN, RapidSVN, TortoiseSVN, Subclipse, and any HTTP client that works with Subversion using an apache frontend are supported. Clients can run under Windows or Linux.
All sites must have identical operating systems and Subversion server versions
J2SE 1.5 or above compliant Java runtime environment. RAM and swapping containers should be three to four times the largest file in the repository. Standard recommendations are 2 GB RAM, 4 GB swapping container for the server. OS support is provided for Windows 2000 and above and Linux 2.6 and above.
Server Versions Supported:
1.11.x, 1.12.x, 2.0.x.
All CVS clients are supported.
All sites must have identical operating systems and CVS server versions
J2SE 1.5 or above compliant Java runtime environment. RAM and swapping containers should be three to four times the largest file in the repository. Standard recommendations are 4 GB RAM, 8 GB swapping container for the server.
Server Versions Supported:
CVSNT server versions 2.0.53 and above are supported.
WinCVS 1.3 and above, TortoiseCVS 1.1.7 and above, CVSNT 2.0.53 and above
All sites must have identical operating systems and CVSNT server versions
J2SE 1.5 or above compliant Java runtime environment. ActivePerl 5.8 or above is required. OS support is provided for Windows 2000 and above, and Linux 2.6 and above. RAM and swapping containers should be three to four times the largest file in the repository. Standard recommendations are 1 GB RAM, 2 GB swapping container for the server.