Home

BitKeeper is paving the way for the next generation of SCM tools. As the leader in distributed configuration management and the culmination of a decade of innovation, BitKeeper has been shown to double the pace of software development.

The BitKeeper Difference IMPROVE DEVELOPER PRODUCTIVITY Reproducible changesets. Automated merging. Freedom from slow networks and server downtime. BitKeeper goes beyond SCM to improve the way you work. IMPROVE WORKFLOW & QUALITY Collaborative workflow. Natural peer-reviews. Incremental development and builds. BitKeeper facilitates agile development and enables higher software quality. TAKE THE BITKEEPER CHALLENGE If you don't see an improvement in your development productivity after one year, qualified candidates can receive a full license fee refund.

Featured Customers   Get the Flash Player to see this player. What They're Saying "BitKeeper is one of the most advanced SCM products on the market." -- HP "BitKeeper allows our development teams to be more agile and flexible in meeting our customers' needs." -- Maxtor

Developers
Are broken builds affecting your productivity?

BitKeeper workspaces are independent replicas where you can check in code, do more work, and continue checking in without polluting the main tree with incomplete work. Check-in, merge, and test -- all in your sandbox -- and push changes up to the main tree when you decide it's ready.

Working remotely? Offline?

Legacy client-server based SCM's may be making your check-ins slow and cumbersome, especially if you have multi-site or remote developers. With BitKeeper, common operations such as check-ins are done locally so they are fast. At the same time, synchronizing repositories over the network is also efficient because only the incremental changes in metadata are transferred.

Want to share, review, and test code easily with other team members?

No problem. BitKeeper enables sideways, peer-to-peer updates that promote collaboration early in the development process. Work, merge, and test collaboratively with team members without ever having to leave a version control environment. No one else is affected until the group is ready to push its changes up to the main tree.

Is debugging and understanding code becoming increasingly difficult?

BitKeeper keeps the most accurate and detailed audit history of any SCM solution in the market with tools to easily query that history. For any modification, developers can quickly see what related changes were committed in the same changeset. BitKeeper's fully annotated history browser also shows all previous versions of each line of code, helping developers quickly see how the code evolved.

Do you have other problems that are impeding your productivity? Try BitKeeper for yourself with a free, no obligation evaluation or contact us at sales@bitmover.com to see if BitKeeper will address your needs.

Architects
Need a better handle on reviewing and quality-controlling your group's work?

BitKeeper makes it easy to create staging repositories where members of a group can check-in, merge, test and work collaboratively without affecting any other group or the main tree. The lead or the architect can then review and push updates to other groups once the changes are ready for prime time.

Getting serious merge headaches right before a release?

BitKeeper encourages developers to merge and test as they go versus checking in most of the work when a deadline approaches. On top of that, BitKeeper's automerge technology is the best in the industry, making it easy to synchronize different branches. Not only does BitKeeper automerge more code than any other tool, it makes sure that merges are done accurately -- without any guesswork. Merges will also never have to be repeated across multiple branches.

Need more detailed and accurate audit trail of who did what, when and why?

Unlike most other solutions, BitKeeper does not lose individual work that went into a merge and maintains accurate authorship down to every line of code. Issues can be quickly isolated to the right changeset, file, line of code, and author. BitKeeper also provides tools to query the history and generate reports or release notes.

Are rollbacks resulting in big productivity loss?

No one's perfect. Sooner or later you may find yourself needing to roll back to a previous state. In BitKeeper, every changeset is a potential rollback point so you will never be burned by forgetting to tag a version. Plus, BitKeeper keeps a full audit trail of every developer's incremental work, ensuring that any and all good work can be replayed in the event of a rollback.

Do you have other problems that are impeding your productivity? Try BitKeeper for yourself with a free, no obligation evaluation or contact us at sales@bitmover.com to see if BitKeeper will address your needs.

Managers
Are hidden costs associated with your SCM adding up?

BitKeeper's total cost of ownership is one of the lowest in the SCM market. Though other solutions may have lower starting license fees, hidden costs including wasted developer time, administrative overhead, hardware costs, and upgrade costs can quickly erode their benefits. BitKeeper not only makes developers more productive, it requires minimal administration and dedicated hardware. BitKeeper's support level is also unparalleled, ensuring that you get the most out of your investment.

Worried about poorly tested code seeping into a shipped release?

We've all been there. You have a critical customer demo that bombs because someone checked in a change at the last minute that seemed harmless. BitKeeper not only encourages changes to be peer-reviewed as they are shared peer to peer, you can easily implement policies where any check-in is applied to a replicated staging repository where acceptance tests are run before the changes are pushed to the main tree.

Need better metrics on who's doing what, when, and why?

BitKeeper's history is more detailed and accurate than any other solution in the marketplace. Unlike other tools, you don't lose incremental work and authorship information on merges. BitKeeper also makes it easy to issue a full range of queries on the work history, allowing you to track developer productivity, project progress, and bug fixes.

Do you have other problems that are impeding your productivity? Try BitKeeper for yourself with a free, no obligation evaluation or contact us at sales@bitmover.com to see if BitKeeper will address your needs.

Products

BK Development Platform
	The BitKeeper Development Platform provides powerful configuration management capabilities and workflow control. BitKeeper was designed to solve many of the scaling, performance, and merge problems that legacy SCM sytems repeatedly introduce. With BitKeeper, developers become more productive, teams can work collaboratively without ever leaving a version control environment, and work is more likely to be peer reviewed. Learn more about how and why BitKeeper will accelerate your development productivity. If you just want to try out BitKeeper for yourself, go to the download and evaluation request form.
BK BAM (Binary Asset Management)
	BK/BAM streamlines the workflow and storage associated with the development of large binary files. Developers have quick local access to those files that are most relevant to their current work, and older binaries are archived in an efficient, organized structure in a centralized location of your choosing. Developers can maintain sparse local trees yet still have access to the full revision history of the files and can gain access or rollback to any prior version, whether tagged or not. Developers also have the luxury of working in local sandboxes with their binary data to prevent disruption of other peoples' work or the main stable tree.
BK Web
	BK/Web is a powerful web interface for browsing and searching BitKeeper repositories that augments the suite of BitKeeper GUI tools. BK/Web provides a detailed graphical interface which outlines project history. Users can search or browse work history based on a variety of parameters including changesets, users, tags, or the files themselves. Typical views include: History summaries Changesets by user Tagged releases BK/Web also includes the ability to search on changeset comments, file delta comments, and file content.

How BK Works

BitKeeper is the configuration management platform for the BitKeeper family of products. BitKeeper arms developers with a distributed, peer-to-peer version control system that naturally enables collaboration, iterative development, and peer reviews.

Developers can work faster and more productively because versioning is local, sharing work is simplified, and all individual work is preserved. Architects and project managers can more easily co-ordinate different components and versions of their projects with BitKeeper's detailed audit trail and advanced on-demand branching and auto-merging capabilities.

How does it work?

BitKeeper groups modifications into logical units of work called changesets, which can represent features updates, patches, etc.

Changesets dramatically improve debugging and maintaining code by showing all of the related changes that are associated with any one modification. Comments are associated with each individual modification as well as the changeset that encapsulates them, making it easy to see not only the who and what, but why.

Easy to manage repositories

At a simplified level, a BitKeeper repository is a collection of files and the group of changesets that captures the evolution of those files.

BitKeeper changesets are committed atomically, never leaving a repository in an inconsistent state. Unlike other SCM solutions, BitKeeper changesets are also immutable and fully reproducible: you can roll back to any changeset and reapply a changeset with the same effect every time.

Since BitKeeper tracks and groups all modifications, including symlinks and file renames, you can always reproduce working builds. Every changeset is automatically tagged in effect, so reproducibility is preserved even if someone forgets to "tag" a version.

No more breaking builds

Legacy SCM systems are client-server based, causing central repositories to become bottlenecks, or worse, single points of failure. In BitKeeper, each developer has a replica of the repository, giving him a revision control environment that is local and sandboxed.

Changesets are committed to the developer's local repository -- slow networks, offline servers, or even offline development no longer hamper check-ins.

Organizations with remote offices, developers working from home, or offshore development will quickly realize the benefits of BitKeeper's fast, localized versioning. At the same time, every organization, whether distributed or not, can decrease the risk of check-in's that pollute global repositories or that break the build for the entire organization.

Fast, lightweight synchronization

Synchronizations between repositories are fast because only the delta in changesets (i.e. difference in metadata) is transferred over the network. Other legacy SCM systems need to traverse the entire directory tree to see what has changed.

Suppose Dave is happy with his new work and is ready to push his changesets to the main repository. Amy can then pull Dave's changes from Main. Files that were concurrently modified are automatically merged wherever possible using BitKeeper's ProMerge technology (if manual merging is necessary, BitKeeper provides advanced 3-way merge GUI tools).

Once Amy has merged, she can push her work to Main. A powerful feature of BitKeeper is that all individual, incremental work is preserved with a detailed audit trail of who did what. If Dave's work turned out to be bad, good work from Amy (and from any other developer) that went into the merge is retrievable. Other SCM solutions typically lose all of the incremental work except that of the last person that merged and checked in.

Collaborating peer-to-peer

Unlike other SCM systems, BitKeeper enables developers to push and pull changes peer-to-peer. This gives you the power to work collaboratively and to leverage each others work without affecting unrelated groups. Organizations implementing Scrum, Extreme Programming, or other agile development methods can now encourage collaboration without anyone leaving a version control environment. People's work is also more likely to be tested and peer reviewed, improving software quality.

On-demand branching

BitKeeper enables a workflow that allows organizations to adaptively divide and conquer projects according to customer priorities. Suppose Dave's feature suddenly turns into a customer priority that requires additional resources. Dave's workspace can be quickly cloned into a staging area that additional developers can work against. Updates, merges, and tests are still sandboxed within the group. BitKeeper's advanced merge capabilities also make co-ordinating updates coming down from Main and coming up from Dave's team easy to manage.

I'm ready to evaluate BitKeeper...

Advantages

• Increased Productivity
  BitKeeper was designed to simplify source management tasks and provide an excellent infrastructure for debugging and reviewing code.
  
  
• Reduce human error
  BitKeeper updates are transactional. BitKeeper runs repository level integrity checks which catch problems immediately, while there is still time to fix them.
  
  
• Reproducibility
  Complex software projects with multiple developers require software configuration management tools that allow for the accurate reproducibility of past and present information. Because BitKeeper supports the concept of a logical unit of work where each unit is immutable -- it cannot change but can be added to -- BitKeeper produces a completely reproducible repository for any moment in time. BitKeeper manages the development process so that every phase of a project can be recreated at a future point in time. Not only are file contents revisioned, but such information as permissions and file deletion events.
  
  
• Accountability
  Because the repositories are completely reproducible at any point in time, it's easy to find out who made what changes, and what other files were changed at the same time. Debugging becomes a much more efficient and less frustrating endeavor with BitKeeper.
  
  
• Disconnected/Distributed Operations
  Every user's work area contains the revision history files such that all work may proceed without any interaction with the main repository, so it's not a necessity to have a TCP connection between all of the systems all of the time. Each work area is a fully functioning repository. Joe can clone a copy of a repository to his laptop and have 100% functionality while disconnected, on an airplane, at a conference, etc. BitKeeper includes tools that propagate changes from one repository to another.
  
  
• Scalable
  A common problem with most configuration management systems is they don't scale. They all work great for 1-5 developers, but they tend to fall apart when you have 1000 developers. BitKeeper's architecture is inherently scalable, so what works for five developers works equally well for 1,000 or 10,000.
  
  
• Excellent merging tools
  BitKeeper has unique merging algorithms that significantly reduce the chance of merge conflicts when compared to other tools. In the rare event of a merge conflict, BitKeeper includes a best in class three-way file merge which makes merging as easy as pointing and clicking. Customers have reported as much as a 18 times reduction in merge time using these tools.
  
  
• Reliability
  Multiple checksums on both the content and revision history of a file ensure that corruption due to hardware and operating system problems are caught early and without propagating through the SCM system. In addition, the distributed nature of BitKeeper repositories eliminates the single point of failure mode that can occur in client-server SCM systems.

Platforms

BitKeeper works well on all of the supported platforms, with the only differences being either performance related (due to the file system) or operating system related (no symbolic links on Win32 platforms). When asked, we tend to recommend Linux as the platform of choice; BitKeeper makes extensive use of the file system and Linux has the the best file system for this application.

The list of supported platforms is currently:

• AIX 4.1.5 and later on PPC
• FreeBSD 2.x, 3.x, 4.x, 5.x and 6.x on x86
• HPUX 11.11 and later on PARISC
• IRIX 6.5 and later on MIPS (to be phased out in bk-5.0)
• Linux/Alpha (64bit)
• Linux/IA64 (Intel 64bit Itanium)
• Linux/MIPS (Sibyte)
• Linux/PARISC (HP RISC platforms)
• Linux/PPC
• Linux/S390
• Linux/SPARC
• Linux/x86 (x86, AMD, Cyrix, etc)
• Linux/x86-64 (AMD Opterons, etc)
• MacOS X on PPC and x86
• NetBSD 1.5 on x86
• OpenBSD 2.7 on x86
• SCO OpenServer Release 5 on x86
• Solaris 5.6 and later on SPARC
• Solaris 5.7 and later on x86
• Windows 2000
• Windows 2000 Server
• Windows 2000 Advanced Server
• Windows 2003
• Windows XP
• Windows Vista (32 bit only)

Please contact us for more information if your platform is not currently supported. We will add support for any POSIX compliant platform for a 50 or more seat sale provided that the system is readily available and is not prohibitively expensive. Tru64 Unix on Alpha support was phased out due to lack of commercial interest but could be brought back for a commercial customer.

Evaluation This section is a hyper link to here.

Customers

BitKeeper is used by many of today's industry leaders covering a wide range of markets. Listed below are just a few examples of companies that have realized the benefits of BitKeeper's innovative technology.

Comparisons

We've gone through the more popular SCM systems available today and contrasted them with BitKeeper based on our research and feedback from customers who have used both BitKeeper and one or more of the other systems.

If your favorite system isn't listed, let us know and we'll try and add it.

FEATURE	OTHER SCM	BITKEEPER	BENEFIT
Inherently reliable through replication	No	Yes	No downtime. Your developers spend their time developing your product, instead of waiting on a server rebuild.
File/directory renaming	Rarely	Yes	Increased productivity through well organized source base.
BK/ProMerge (tm)	No	Yes	Accurately reduces the number of merge conflicts, eases resolution of remaining conflicts.
True distributed system	No	Yes	100% productivity at geographically distributed sites at all times, with no loss of functionality or performance. Any user may modify any file on any branch at any time, without restriction.
Powerful GUI tools	No	Yes	Dramatically simplifies debugging, easier merges, improves check in comments.
All changes are reproducible snapshots	No	Yes	Easily remove bad changes, aids in debugging, aids in release management.
Web project tracking	Maybe	Yes	Allows management to track projects and estimate release dates.
Optimal performance for all users, local or remote	No	Yes	Database replication means all developers, local or remote, get optimal performance. BitKeeper works well even over low bandwidth, high latency links such as modem or satellite links.
Disconnected (laptop)	No	Yes	Productivity while traveling, at home, at remote offices with partial/slow network connectivity.
Peer-to-peer architecture	No	Yes	Work may flow in any direction, including "sideways" between two developers without involving a "master" copy.
Painless upgrades	No	Yes	Upgrading server does not affect developers.
Cross platform GUI	Rarely	Yes	Increased productivity, no retraining.
Scripting	Maybe	Yes	Easily customizable to your environment.
Customizable reports	Rarely	Yes	Accountability and status to/for managers.
Automatic integrity checks	No	Yes	Catches hardware/software problems promptly, while replicas are still available.
Active roadmap	Maybe	Yes	BitKeeper is actively developed by a world class development team. Follow on products for bug tracking, sales tracking, project management, project hosting are all actively being developed.

CVS

• CVS is in widespread use, mainly because it is free. It works fairly well for simple tasks, it's better than just using RCS. It has problems as the development effort gets large.
• CVS has a single repository model. Each work area is clear text only which means no revision control in the work area during development.
• No staging areas to protect the main source tree. With CVS, everyone checks into the same place and if someone breaks the tree, it's broken for everyone. With BitKeeper, you can put a staging area between each group of developers and the main integration tree, thereby protecting the main tree from bad checkins. Anyone who has lived through a change that broke the build can see the value of staging areas.
• CVS loses information every time there is parallel development because you are forced to merge before you check in if someone else checked in first. The state of your workspace before the merge is lost forever. Another way to say this is that if there is N-way parallel development, CVS loses N-1 events.
• Merging in CVS is primitive at best.
• Branch management in CVS is a nightmare.
• CVS has no change sets, i.e., no atomic commits of changes which span files.
• CVS has no integrity checker which means files can be silently corrupted and you will never know until you try and roll backwards.
• CVS has no rename support.
• CVS was based on RCS and still has RCS' limitations.
• On the plus side, CVS is free, works well enough for some development projects, and CVS repositories are easily converted to BitKeeper. If you can't afford a good source management product, use CVS, we'll help you migrate off of it when the time comes.

Subversion

Subversion is a new system which is supposed to replace CVS. Unfortunately, Subversion shares many of CVS' problems and introduced some of its own problems:

• Subversion uses a binary file format for your revision control data and metadata and if that format gets corrupted you are out of luck, your whole team comes to a halt.
• Subversion has a single repository model, i.e., client/server. Each work area is clear text only which means no revision control in the work area during development.
• No staging areas to protect the main source tree. With Subversion, everyone checks into the same place and if someone breaks the tree, it's broken for everyone. With BitKeeper, you can put a staging area between each group of developers and the main integration tree, thereby protecting the main tree from bad checkins. Anyone who has lived through a change that broke the build can see the value of staging areas.
• Subversion loses information every time there is parallel development because you are forced to merge before you check in if someone else checked in first. The state of your workspace before the merge is lost forever. Another way to say this is that if there is N-way parallel development, Subversion loses N-1 events.
• Merging in Subversion is no better than CVS, i.e., primitive at best.
• Branch management in Subversion is a nightmare.
• Subversion has no integrity checker which means files can be silently corrupted and you will never know until you try and roll backwards.
• Subversion has only weak rename support, that's something that is inherent in all centralized systems.

Perforce

Perforce is commercial tool similar in design to CVS. For small development efforts, it works as well as CVS for a lot of things and better for some others.

• Perforce is similar to CVS and shares some of the same problems, such as a central repository, only one repository, and no per work area history. It does have weak rename support and groups changes, but does not have true changeset support.
• Perforce does not provide per file commentary; only per change set commentary. It's a minor point, but sometimes you want that extra information, it helps the debugging process.
• Perforce loses information every time there is parallel development because you are forced to merge before you check in if someone else checked in first. The state of your workspace before the merge is lost forever. Another way to say this is that if there is N-way parallel development, Perforce loses N-1 events.
• Perforce chooses speed over accuracy. The system remembers the set of files you have locked and prompts about only those files at checkin time. If you have added any files to your workspace, Perforce ignores those.
• Merging in Perforce is primitive at best.
• Perforce maintains state in a database next to the RCS files. In order for this state to be consistent with the RCS files, you must access the RCS files only through the Perforce daemon. The database is a single point of failure; if it gets corrupted, your source management system does not work. The real problem is that when the database gets corrupted, there is a high chance that you need Perforce to straighten it out.
• The Perforce daemon is a bottleneck. Long running operations lock out all other users. This isn't a problem with small repositories, only with large ones. Scalability becomes a problem.
• The database can use a dramatic amount of disk space.
• Upgrades are not reversible and lock the system for hours.
• Perforce has an integrity checker but it is only run if you ask for it, i.e., the default is to just hope that the data is correct. That means your data can get silently corrupted and you will never know until you try and roll backwards.
• The main issues are scaling, reliability, and accuracy. Perforce is marketed as the fast SCM system but it chooses speed over correctness. All systems with centralized repository have scaling problems, that is inherent in the design. Perforce has made an effort to make their database reliable, but even so, it can get corrupted, frequently through no fault on Perforce's part, i.e. a disk goes bad. When that happens, your development stops.
• Perforce uses the RCS file format with all of the problems that entails.

Perforce is a trademark of Perforce Software, Inc.

ClearCase

• ClearCase is integrated into the operating system as a file system. Experience has shown that this can be problematic each time the operating system is upgraded.
• ClearCase is slow for many common operations when compared against a local filesystem.
• ClearCase is quite resource hungry - it is not uncommon to spend as much as $300,000 for a large SMP server to serve up 20 developers. A $2000 PC can (and does) do the same job with BitKeeper.
• ClearCase is expensive in more ways than just seat costs. The hardware and administrative costs to run a ClearCase server can dwarf the seat costs. It is common to allocate a full time administrator to manage the ClearCase server and software.
• The ClearCase multisite feature is an attempt to decentralize a centralized system and it doesn't work as well as a truly distributed system. The basic idea is that each site gets a branch, that branch is writable by that site only, the other site's branches are read only. BitKeeper has no such restrictions, all sites can work on the same branch at the same time.
• BitKeeper improves debugging efficiency of developers through changesets; it is trivial to go from a line of code to the changeset which introduced that line.
• Development managers can perform better code reviews with BitKeeper.
• Management can easily track project progress through the BK/Web interface.
• BitKeeper is easier for administrative staff to learn and support.
• BitKeeper is more reliable - all repositories are database replicas.
• BitKeeper allows full-development efficiency at remote sites, with no loss of performance or functionality.
• BitKeeper saves money through dramatically reduced hardware requirements.
• BitKeeper is fast - maintains single user performance levels.
• Summary: ClearCase is the mature market leader, but has a centralized architecture which implies many limitations. BitKeeper has a proven distributed, replicated architecture without those same limitations. Total cost of ownership with ClearCase can easily exceed 5 times that of BitKeeper for the same development effort.

ClearCase is a trademark of Rational Software Corporation.

Sun Teamware

• BitKeeper has changesets, Teamware does not. Changesets guarantee that the tree is reproducible, Teamware can not.
• BitKeeper rollback always works, Teamware rollback rarely works.
• BitKeeper can import/export diff-style patches for the entire tree.
• Many of the BitKeeper graphical tools are substantially better than the ones in TeamWare. The BitKeeper file merge is easier to use, works better, and merges faster. Citool is a graphical checkin tool which reduces human errors (missed files) and produces better checkin comments. There are no analogous tools in TeamWare for citool, difftool, renametool, csettool or helptool.
• All of your TeamWare knowledge transfers over -- conceptually, BitKeeper is similar to TeamWare.
• BitKeeper has better event triggers (more fine grained control).
• BitKeeper has much better rename support for files and directories. Renames in Teamware are not an undo-able event.
• BitKeeper uses much less bandwidth when synchronizing with remote repositories over the WAN or dial-up (null updates take less than a second over an SSH connection regardless of repository size).
• BitKeeper has compressed repositories. In one import of 19 years of Teamware managed data the size of the resulting repository was slightly more than 2 times the size of the checked out files. In other words, BitKeeper was able to store 19 years of changes in the same space as the flat, checked out files. No other SCM system comes close.

VSS

Visual Source Safe is a low end commercial tool that integrates with the Visual Studio environment.

• Visual Source Safe has a single repository model. Each work area is clear text only which means no revision control in the work area during development. If the VSS repository goes down for any reason your developers are down.
• VSS does not have changesets.
• VSS loses information every time there is parallel development because you are forced to merge before you check in if someone else checked in first. The state of your workspace before the merge is lost forever. Another way to say this is that if there is N-way parallel development, VSS loses N-1 events.
• Merging in VSS is primitive at best.
• Branching can be a nightmare.
• Integrity checks are not done automatically with VSS. Data corruptions are a common occurrence with VSS and manual checks are recommended frequently.
• VSS does not have replicated repositories, this means no work flow support, no disconnected operations, etc.

RCS

RCS is not an SCM system, it is a file based system. However, many commercial systems use the inferior RCS file format so we felt it was worth having RCS in the comparisons.

• RCS has no checksum. RCS files can get silently corrupted and RCS will never notice unless you happen to ask for a delta that is part of the corrupted area of the file. Because of the way RCS is designed, it is unlikely to ever notice a problem until too late. BitKeeper checksums the entire file as well as each delta and verifies the checksum on each operation.
• Lack of compression. BitKeeper supports compressed contents. The administrative part of the file (typically less than 5% of the file size) is uncompressed; the rest may be compressed to gain back disk space and use less disk/network bandwidth.
• RCS has no rename support. BitKeeper records pathnames with the deltas so that files may be moved around easily without losing track of where they once lived.

Sales

This section gives details about how to purchase BitMover's products. We offer a free, no obligation evaluation of our products and the evaluation can be conducted without any impact to your existing history or environment.

We offer a range of product purchasing options that can be tailored to your needs, whether you are a startup or a global enterprise. Licenses can be purchased or leased on an annual basis, with support and upgrades included in the annual licenses. Also, you can take advantage of various incentive programs that will decrease both risk and cost in your buying decision.

To request a quote or an evaluation key please fill out the license request form.

For information and assistance, please send a query to sales@bitmover.com or call BitMover at 888-401-8808.

Evaluation This section is a hyper link to here.

Do you need BK?

SCM systems are often a productivity bottleneck. Inexpensive entry level systems don't solve the problems you need solved. Traditional high end systems are resource and administration intensive. BitKeeper is light, fast, and exceptionally simple to use, yet it offers advanced features not found in even the most expensive traditional systems.

• Productivity
  BitKeeper is a developer's tool, it puts more power in the hands of the developer while allowing enough structure to manage your projects. BitKeeper's peer-to-peer and replicated architecture spreads the load over all your machines, significantly reducing server and network bottlenecks. BitKeeper provides a full suite of features to speed up all of the operations that your developers use most frequently.

• Reliability
  BitKeeper performs regular consistency checks without having to take your system offline. BitKeeper's architecture allows your developers to continue working locally with full functionality even if your server goes down or you experience a network outage. And it provides inherent backups through replication. It is possible and easy to guarantee 24x7 uptime with BitKeeper.

• Flexibility
  BitKeeper is a peer-to-peer system, that seamlessly supports customized work flows. Whether a small or large shop, BitKeeper can adapt to your development process and then grow with you as your needs change. BitKeeper's Delta Development model epitomizes the flexibility and scalability that is achievable with our peer-to-peer architecture.

• Total cost of ownership
  The total cost of an SCM solution goes far beyond the price of the software. With many tools, the real cost lies in administration, hardware, support, and professional services. With BitKeeper those costs are negligible. The replicated nature of BitKeeper means that a PC will work fine and there is no need for full-time admins. A small and cheap PC can easily support thousands of developers. It would cost more than a hundred times as much to do the same thing with other SCM solutions.

• Support
  Our support is without equal in the industry, we are responsive and will work with you to deploy BitKeeper effectively, at no extra charge. BitMover does not have multiple layers of support, you can talk directly to an engineer that can solve your issues. Our customers frequently describe our support as the best they've ever received.

• Remote/distributed development
  With centralized client/server SCM systems, all remote people and teams suffer. BitKeeper is a peer-to-peer system based on a replicated database. All teams become local and enjoy local performance in a replicated system.

• Merging
  BitKeeper's ProMerge has best-in-class merge algorithms and merge tools which reduce merge time to 1/10th of the time required by other tools. Many customers claim that the man hours savings in merging alone more than covers the software cost.

• Reproducibility
  BitKeeper guarantees 100% accurate rollback of all file contents, names, and permissions without requiring any forethought on your part. While other systems require that you remember to tag the tree, BitKeeper has no such requirement; all changes are potential rollback points.

• Reviewing and debugging code
  BitKeeper maintains more history detail with more accuracy than any other tool currently available. We also have a suite of tools that allow you to get a quick picture of your development history at a high level and instantly delve into specific detail.

• Renames
  BitKeeper gets this right, files may be renamed at any time, in any work space, and the renames are handled correctly in all cases.

If you are interested in enjoying the benefits of BitKeeper please request a quote or an evaluation key through our online request form. For information and assistance, you may also send a query to sales@bitmover.com or call BitMover at 888-401-8808.

How to buy

BitKeeper prices depend on a variety of factors including which products you choose, whether you choose to lease or buy, and the number of licenses you need. The total cost of SCM includes more than just seat price. The full set of costs are discussed in our total cost of ownership section which demonstrates how BitKeeper can be significantly less expensive than any other offering, free or commercial.

We offer two different methods for licensing BitKeeper, allowing you to choose which method best fits your business requirements.

Buy option: this is the traditional way of purchasing software, you pay a one time fee and have the right to use that version of the software indefinitely. This model includes the first year of support and maintenance, with additional years available for a yearly fee.

Lease option: this is the new preferred model in the software industry. Leasing has become very attractive with software buyers who see the advantage of smaller annual payments, included support, and included upgrades. This means you can always get the latest version without having to retire your old software and buy it again every year or two. This option has proven to be quite popular with our customers because it is substantially less than the purchase price and is paid annually.

BitKeeper can be purchased in the following packages:

To request a quote or an evaluation key, please fill out the license request form.

For information and assistance, please send a query to sales@bitmover.com or call BitMover at 888-401-8808.

Cost of ownership

The total cost of ownership of any SCM product needs to be balanced against the benefits in order to make an informed purchasing decision. While it is usual to consider only the software costs, doing so can lead to an inaccurate view, resulting in unpleasant surprises down the road. The real cost of ownership is the sum of:

• Licensing costs
• Hardware costs
• Human costs

All of these need to be assessed in order to see the true cost of any system. For some products, it turns out that the people and hardware costs dwarf the cost of the software.

The following chart quickly illustrates hidden costs of other SCM products.

COSTS	OTHER SCM	BITKEEPER
Software licenses	$-$$$$	$$$
Setup	$$-$$$$$	$
Hardware	$$$-$$$$$	$
Administration	$$-$$$$$	$
Third party databases (if needed)	$$$$	0

Licensing costs. Paid BitKeeper licenses are needed for each person who uses the software to make changes of any kind. Read-only users (people browsing the source, tracking progress, doing builds, etc.) still need a license but there is no charge for that license. In general, our software delivers productivity increases and time savings far in excess of the annual lease investment.

Hardware costs. Software requires hardware, and SCM software has traditionally required a great deal of hardware. Consider that virtually all other SCM systems have a centralized design where the SCM system runs on a single server. The performance of that server is a function of the server itself and the number of concurrent users. If there is only one user, a modest server will perform quite well, but as the number of users increases, the hardware must also be improved or performance becomes unacceptable. Unfortunately, the cost of performance is not linear. A system which is twice as fast is rarely only twice as costly, and a system which is ten times as fast is always much more than ten times as much.

The problem is obvious, a centralized SCM system will add hardware costs at what can be an exponential rate as the number of users increases. This translates into reasonable costs for 5-10 users and unreasonable costs for 100-1000 users.

BitKeeper does not have this problem because of its distributed model. The main repository is rarely used, work takes place in the child or grandchild repositories and then fans into the main repository. This model means that the hardware costs can be spread over a set of inexpensive PCs rather than a $300,000 SMP machine. BitMover hosts repositories used by thousands of developers on a single inexpensive server.

Human costs. Many SCM systems have traditionally required an administrator for every 10-20 users. These administrators are critical when the SCM is a centralized single point of failure. If an administrator costs $200,000 (salary, benefits, and other overhead) and one is needed for every 20 users, that is a not-so-hidden additional cost of $10,000/user/year. One may argue that a well run installation could do better, perhaps one administrator per 100 users, but that is still an additional $2,000/user/year. BitKeeper eliminates the need for an administrator, it has no single point of failure. The savings realized by not needing an administrator to nursemaid the SCM server will easily cover 100% of the cost of BitKeeper.

Note that an administrator is not the same as a project lead who defines and controls policy in the repositories; all development efforts of any size will need people in that role and no SCM system can remove that requirement. An administrator is the person who makes sure that the hardware and the software is working, the repositories are backed up, etc. The distributed nature of BitKeeper removes the need for such a person.

Incentives

The BitKeeper Challenge   Full refund if you don't see value. No other SCM product can offer this kind of guarantee. Seeing the value. BitKeeper's customers consistently achieve productivity gains that far exceed their initial expectations and we're confident that you will too. However, we at BitMover believe that there is no substitute for using a product in-house over the course of a year to really understand its benefits. Improving developer workflow and productivity, decreasing hardware and administration costs, and eliminating problems with slow networks or server downtime will quickly add up in savings unlike any other solution. Full refund. We are so confident that you will achieve significant ROI with BitKeeper that we will fully refund your license fee after the first year if you do not see the value and elect to discontinue use. Check the competition to see if they're as confident about their SCM tool. Minimal to zero risk. If you choose to migrate off of BitKeeper after completing the challenge, we will help you export your BitKeeper repository into a standard SCM tool. Since BitKeeper maintains more metadata than other SCM tools, data that you would have collected during the course of the year with another SCM tool will be preserved. How to qualify. The BK challenge is available to new customers that sign on for a minimum of 10 developer seats of either BK/Pro or BK/Enterprise at the beginning of the first license year. The BitKeeper Test Drive and a one hour free process consultation must also be completed within two weeks of receiving the evaluation key. Contact us to inquire about additional details and how you can qualify.     License Buffer   Our customers find BitKeeper is so valuable that its use typically expands beyond the traditional developer. Support engineers, part time developers, consultants, QA, and build engineers frequently demand BitKeeper and we'll help pay for those users. For qualified customers we will provide 5 additional seats at no charge to cover expansion beyond your core developers.     Trade-In Program   First time customers may qualify to trade in their old, inefficient source management tool in order to offset up to 50% of the investment in BitKeeper. Contact us for details.

Test drive

Thank you for trying BitKeeper!

The following demo will walk you through:

• Installing BitKeeper
• Creating your own workspace (cloning a repository)
• Browsing the history of the repository using bk revtool
• Searching, reviewing, and debugging
• Updating a repository
• Viewing the updates
• Making your own changes
• Merging your work with another person's work

You will need to type some commands and run some graphical tools. You will see prompts like this:

Command-line prompt: When you see this, type it in the shell.

Graphical prompt: When you see this, do it in the BitKeeper GUI.

Graphical prompt for Windows: When you see this, do it in the Windows GUI.

The demo was designed to be done in under 30 minutes.

Installation

In this section you will install the BitKeeper product.

If you have not downloaded BitKeeper you should request an evaluation key and download information now.

Once you have downloaded the software, continue with the installation directions for your operating system.

Unix

The image you download is an executable file and your license keys are imbedded in it. In case your browser did not preserve the permissions, do:

chmod +x installer_binary

Then run the installer:

./installer_binary

The default is to run the graphical installer. To run the command-line installer, set the destination directory on the command line:

./installer_binary destination_dir

Windows

The image you download is an executable file and your license keys are embedded in it.

Double-click on the x86-win32 icon. You can safely use the defaults for all prompts.

Once BitKeeper is successfully installed, open a cmd window to run the demo:

Start -> run -> cmd

Mac OSX

The image you download is an executable file and your license keys are embedded in it. You will need to run the executable from a terminal window. In case your browser did not preserve the permissions, do:

chmod +x installer_binary

Then run the installer:

sudo su - cd download-dir ./installer_binary

When prompted, enter your own password. The default is to run the graphical installer. To run the command-line installer, set the destination directory on the command line:

./installer_binary destination_dir

Cloning a repository

Cloning is the term we use to describe the process of getting a personal workspace. Your workspace is your copy of both the source code and the revision history. You browse, modify, and check in changes to your workspace.

In the cloning section you will:

• Clone a demo repository from bkbits.net to your local machine; this repository will act as the "server" repository.
• Clone a workspace from the "server" repository you cloned from bkbits.net.

Go to a directory or folder of your choice.

mkdir BK cd BK bk clone http://bkdemo.bkbits.net/bk_demo my_parent

This creates a complete copy of the workspace in BK/my_parent.

If it doesn't work, you might need to tell BitKeeper about your HTTP proxy, which you can do by

# shell export http_proxy=http://your_proxy.your_company.com:80/ # cshell setenv http_proxy http://your_proxy.your_company.com:80/ # Windows cmd.exe set http_proxy=http://your_proxy.your_company.com:80/

For more information about methods of accessing repositories see the manual page

bk helptool url

Try this now and go to the next page after it is completed.

Cloning a child

Because the demo does not allow you to push changes back to bkbits.net, you need to clone again so that you have a local parent and child. This also demonstrates same file system clones.

bk clone my_parent bk_demo

You should now have a directory with two subdirectories: my_parent and bk_demo. There is a recorded relationship to the parent repositories. bk_demo knows that it gets updates from and sends updates to my_parent and my_parent knows it gets updates from and sends updates to http://bkdemo.bkbits.net/bk_demo.

Using bk revtool

There are ways to browse the repository both graphically and via the command line. The following example shows you how to browse a repository and file history using the graphical revision history browser, bk revtool.

Repository history is grouped by changesets. A changeset is a grouping of one or more changes to one or more files, and it is what is propagated between BitKeeper repositories. Changesets are stored in a revision controlled file named ChangeSet and can be browsed graphically. To do so:

cd bk_demo bk revtool

When in bk revtool, do:

Click on Select Range. Click on All Changes.

Things to notice:

• invoking bk revtool with no file argument displays the history of the entire repository, which is contained in the ChangeSet file.
• the top window displays boxes representing changesets containing the name of the person who made the changeset and the changeset revision. Tagged changesets are highlighted with a yellow box.
• the bottom window displays changeset information.

Repository history

Left-click on the box that says "tytso 1.111" .

The bottom window contains the comments for the changed files as well as the changeset comments.

Left-click on rev 1.111. Right-click on rev 1.114 (Cmd-click on Macintosh).

The bottom window now contains the comments for all changes from rev 1.111 and 1.114, inclusive.

Scroll back to find the 1.107 changeset.

Things to notice:

• The "branched" graph from node 1.107 represents parallel development.
• All work is recorded, including branch points as separate nodes. Each of these nodes is a reproducible snapshot of the repository.

Stay in bk revtool; on the next page you'll look at file history.

File history

Click on node 1.114.

You should be looking at a changeset which has modifications to pass2.c.

Left-click (single-click) in the comments below the e2fsck/pass2.c file.

Another bk revtool appears; this one displays the history of pass2.c. Revision 1.36 of pass2.c is the delta in the 1.114 changeset. bk revtool is displaying the differences between the revision of interest (1.36) and its parent (1.35). We can now explore this file further.

Click Select Range. Select All Changes.

To see the differences introduced by this delta:

Left-click on 1.35 and right-click on 1.36 (Cmd-click on Macintosh).

The differences are displayed in the text window. To see side by side differences with all the file context in a new window:

Click Difftool in the menu bar at the top of bk revtool. In bk difftool, press the spacebar to walk through the diffs. Press "p" to go to the previous diff. Click Quit when done. Click Quit in the bk revtool window that has ChangeSet in the title bar.

Stay in bk revtool with pass2.c in the title bar; on the next page you'll do some searching.

Searching

Suppose that you are looking for a particular change in pass2.c. Start by getting an annotated listing by

Double-click on a node in the graph; let's choose 1.35.

You should see lines like

tytso 1.1 /*
tytso 1.1  * pass2.c --- check directory structure
tytso 1.1  *

Suppose that you were trying to track down a bug in symlink handling. You know that the problem has something to do with a function with pass1_check in its name. To find this

Press "/" and notice that the focus is in the search window at the bottom. Type in "pass1_check" and press "Enter". That's not the right one; press "n". Press "n" exactly 3 more times.

That's the one you want. But you remember it being different so you would like to see what it was like before this.

Left-click on the line containing e2fsck_pass1_check_symlink.

Notice that the highlighted node in the graph is now the one corresponding to the line you just clicked. To see the changes for this revision,

Press "d".

Repeat the search process to find the call to e2fsck_pass1_check_symlink:

Press "/". Type in "pass1" and press Enter. Press "n". Left-click on the line with pass1 highlighted.

Stay in bk revtool; on the next page you'll look at the changeset that added that line.

Viewing a changeset

You should be on revision 1.34 in the history of pass2.c; if not go click on that.

Now that you have found the version of the line you want, you might want more information about what was happening when this change was made. This information can be helpful in tracking down the root cause of a bug.

Click on View Changeset at the top of bk revtool.

A new window, labeled Cset Tool, should appear. This window has 4 panes.

• The top left pane is the list of files in this changeset; you can click on a file to make it active.
• The bottom two windows show the before and after versions of the active file. You can move through the diffs by pressing the spacebar.
• The top right file has the changeset checkin comments followed by the checkin comments for the active file.

Browse around in the changeset viewer. Try clicking the files, moving through diffs, etc.

When you are done, click Quit in all BitKeeper windows.

At this point you should now be familiar with viewing repository and file revision history using bk revtool.

If you would like to use command-line tools to browse history, please read the help pages for bk changes and bk log:

bk help changes bk help log

Updating your repository

Next, you will update your repository using bk pull.

• The first pull will be from the parent and will have no updates
• The second pull will be from an alternate repository and will have updates

The bk pull command can be used with or without specifying a BitKeeper URL. Using bk pull without a URL argument pulls from the parent. With a URL, BitKeeper pulls from the repository specified by the URL. By default, the parent is the repository from which the current repository was cloned.

bk pull

It should have told you there was nothing to pull, which is correct; that repository has not changed. Let's go pull from a different repository which does have changes:

bk pull http://bkdemo.bkbits.net/bk_demo1

You now have learned how to get updates from the parent repository or an alternative repository.

Go on to the next page to make your own changes.

Making changes

In this section you will learn about and become familiar with

• file modes and checking out files for editting
• checking in both modified and new files
• creating changesets
• viewing the new changes

Checkouts

Before you actually make any changes, it is important to get acquainted with how to check out files in BitKeeper.

Cleaning a directory

cd e2fsck

Notice the directory is populated with files. Now do:

bk clean

Notice that the files are now gone. The SCCS directory is where the revision histories for the files in the directory reside. On Windows the SCCS directory is hidden by default.

Checking out
There are two modes for checked out files in BitKeeper: read-only mode and read/write mode.

To check out (or get) the files in read-only mode do:

bk co

Notice that the directory is now populated.

Now check out the files in read/write mode:

bk edit

Notice that the files are now read/write capable and thus can be modified.

To put the repository back in its original state, do:

bk clean bk co

Checkout Modes

By default, BitKeeper operates in a "clean" checkout mode such that all files must be explicitly checked out. It can also run in other checkout modes: get mode and edit mode.

The repositories you have cloned for this demo run in checkout:get mode and consequently all files in the repository are checked out in read-only mode. If you run in checkout:edit mode, all files in the repository are checked out and can be modified.

Modifying a file

Please do the following modification to recovery.c:

bk edit recovery.c Edit recovery.c in a text editor. Change all instances of "jread" to "Jread".

Creating a file

Create a new file:

echo "/* New File */" > foo.c

Notice that you did not tell BitKeeper that this file needs to be revision controlled; you'll do that later.

Viewing the changes

Often it is useful to see what changes have been made that haven't been checked in yet. You can use bk difftool or bk diffs to view differences.

Try the command line first; you should see the jread changes:

bk diffs

And to see which files are not yet under BitKeeper control:

bk extras

Then try the graphical tool:

bk difftool

As with most BitKeeper graphical tools, you can use the "n" key to get to the next diff and the "p" key to get to the previous diff.

bk difftool displays the differences between the last rev and the modified versions of the file if run without options and the file argument is a modified file. With no arguments, it shows diffs for all modified files in the current directory.

Click Quit in bk difftool.

Checking in changes

Checking in files and creating a changeset can be done via the command line or with bk citool, the graphical check-in tool. We recommend using bk citool because it shows the changes made to each file which improves the quality of the comments. Steps for the graphical tool are shown first followed by steps for another file edit and the command-line check-in.

Using bk citool:

bk citool

Add comments about the changes in the middle window. Click on the icon next to foo.c to add this file to the repository. Click on ChangeSet. Add comments about the ChangeSet in the middle window. Click on the Commit box at the right. Click on the Commit box again to confirm you are done.

You have now checked in your changes, added the new file foo.c, and grouped these changes into a changeset. Next you will check in changes using the command line:

echo foo > bar.c bk new bar.c bk edit foo.c echo "This is file foo.c" >> foo.c bk ci -y"These are the checkin comments" foo.c bk commit -y"These are the changeset comments"

To see the changes you've just made:

bk revtool

Double-click on the box containing "your_login 1.125". In the bottom window, click on the line under "e2fsck/recovery.c".

The history of the recovery.c file is shown in another bk revtool window. You can use bk revtool on files in the same way you can use it on a repository.

Click Quit in all BitKeeper windows.

Merging changes

The next part of the demo will illustrate how to merge conflicts. BK/ProMerge can complete many complicated merges automatically, but there will be times when there are merge conflicts that need to be resolved by a human being.

The BitKeeper update process does not apply changes to your repository until they have been merged. Instead, the changes are pulled into a sparse repository called the RESYNC repository. When there are conflicts to merged, the bk pull command tells you that as the last part of the output.

In the following section you will learn

• what bk pull outputs when it can not automerge
• how to run the resolver to resolve a conflict
• what the file merge tool looks like and how to use it
• how to check-in once you have performed a manual merge

Let's go see how that works.

Pulling and resolving a conflict

When you pull in a conflict that must be merged manually, BitKeeper will automatically run the resolver and will prompt you to resolve the conflicts. Let's pull in a merge conflict:

cd .. bk pull http://bkdemo.bkbits.net/bk_demo2

You should see:

---------------------- Receiving the following csets -------------------------- 1.124 ---------------------------------------------------------------------------- ChangeSet: 1 deltas e2fsck/recovery.c: 1 deltas --------------------------------------------------------------------------- takepatch: saved entire patch in PENDING/2006-07-07.01 --------------------------------------------------------------------------- Applying 1 revisions to ChangeSet, renumbering, checking checksums Applying 1 revisions to e2fsck/recovery.c takepatch: 2 new revisions, 2 conflicts in 2 files 569 bytes uncompressed to 1363, 2.40X expansion Running resolve to apply new work ... Conflicts during automerge of e2fsck/recovery.c resolve: 1 unresolved conflicts, starting manual resolve process for: e2fsck/recovery.c (content conflict) e2fsck/recovery.c>>

Because bk pull encountered merge conflicts, it runs the resolver, which prompts you to resolve the conflicts. (You can run the resolver manually with the bk resolve command.) The resolver can handle a number of different conflict types, such as content or rename conflicts. Each conflict type has its own resolver "plugin" with a type specific set of commands. In this example, you will be handling a content conflict.

Press "Enter" to see the command options. Press "f" and "Enter" to run the 3 way file merge.

File merge

You should see a multi-pane graphical tool. It has 6 panes:

• The first "row" contains two small side by side windows. These contain the checkin comments for the active diff.
• The next row contains two larger side by side windows. Each of these is a "stacked diff" window, showing the changes from the common ancestor to the local (left window) or remote (right window) versions of the file. The active diff is the one with lines highlighted the width of the window. The darker highlighting with the leading "-" represents the lines in the ancestor and the lighter highlighting with the leading "+" represents the lines added by the local or remote version of the file.
• The merged file is shown at the bottom left.
• The smaller lower right window contains instructions for the active difference or conflict. There is also a status bar which contains information about which conflict you are on out of how many.

Each conflict that must be resolved by hand highlights the status bar in red. To select a line or block simply click in the upper left or upper right boxes on the line or block that should be in the merged file. So, in the example, you're going to keep the changes you made and complete the merge.

Click in the upper right window on the line with "jREAD" highlighted in orange. Press "u" to undo since you want the "Jread" changes. Click in the upper left window on the line with "Jread" highlighted in orange. Press the "]" key to go to the next conflict. Click in the upper left window on the line with "Jread" highlighted in orange. Press the "]" key. Repeat until all conflicts have been resolved. Type "s" to save.

Checkin

The file merge tool should have dropped you back into the resolver interface. If you are sure that you want to keep the merged changes you are ready to commit the merge:

Type "C".

If there were more files with conflicts, the resolver would prompt you with the next conflict. Since this is the only conflict, the resolver then brings up citool to allow you a chance to comment the merge changes.

Type in comments for all files. Click Commit twice.

Update the parent

What you have done so far is to make local changes and merge in changes from a different repository. You have not yet updated the parent with your changes; they are only in your repository.

In this section you will learn

• how to use bk changes to see if there are local only or remote only changes
• how to use bk push to update another repository with your changes

You can see if there are changes in the parent (or remote) repository that aren't in your repository by running

bk changes -R

You shouldn't have seen any changes.

You can see if there are changes in your local repository that aren't in the parent by running

bk changes -L

To update the parent repository, you need to do what is known as pushing, i.e., you push your changes to the parent repository. To see where changes will go, run the bk parent command and then push:

bk parent bk push

After you push, the parent and your local repository are exactly the same. If you pull or push, nothing should be transferred. Let's see what happens when you try a bk pull:

bk pull

You should not have received any updates.

You have now updated a repository with the changes that you made.

Finis

Congratulations! You have successfully run through some of the basic and some of the more complex BitKeeper operations. You've seen how to get views of the repository and its files via the command line and via the graphical tools. You have made modifications to a file, added new files, checked in those files, and created a changeset. And finally, you've run through a merge with conflicts that needed to be resolved by hand.

You might want to delete the BK directory you made along with all the demo repositories.

For more information about BitKeeper commands, try one of the following:

bk helptool bk help topic bk help -k keyword

If you need further assistance, you can find it at support@bitmover.com.

A next step in learning about BitKeeper is to try it on your own data. If you would like to talk to a representative about doing a conversion of your current tool's data, please send mail to sales@bitmover.com.

Thank you for trying BitKeeper and we hope you liked your tour.

Company

BitMover is a privately held company incorporated in 1998 in the state of California. We are headquartered in Silicon Valley and maintain distributed development groups in the United States, Canada, and Germany. Our mission is to deliver the infrastructure required for software, hardware, web, and other computer based development.

BitMover's dedicated engineering team has been working on our flagship product, BitKeeper, since mid 1997. Because we make tools which excel in today's distributed development environments, we use our own products for our own development and have been successfully doing so since 1998.

BitMover is profitable and is experiencing dynamic growth. The majority of our sales are generated from the referrals of satisfied BitMover customers.

What we do

We develop tools used for software, hardware and web development. Our initial focus has been on a scalable source management tool called BitKeeper.

We have invested heavily in the development of BitKeeper and are now leveraging that investment by using the software as a basis for new applications, such as bug tracking, sales tracking, invoice tracking, project tracking, project management, project hosting, etc.

Our roadmap has us developing and deploying these applications as well as grouping them together to form what we call a virtual developer ASP. BitKeeper lets you take your source with you. Our ASP will let you take your source, bug database, to do list, mailing list, and any other required data with you. The ASP model as it stands today has one fatal flaw: some company you may or may not trust holds your data. The BitKeeper ASP is a distributed, replicated, suite of databases holding source, bug tracking, mailing lists, and everything you need for your development projects.

The BitMover difference

BitMover is a unique company. We provide a strong focus on engineering excellence with an equally strong focus on our customers. We have a solid, old-fashioned work ethic and a dedication to quality which shows in our products and throughout our development process. If you report a problem to us, our commitment is to not only fix it, but to develop a regression test that ensures you will never see the same problem again. We have developed proprietary clustering technology which allows us to test our software on more than 30 different platforms before you see it. No matter how well we are doing, we know we can always do better. We are constantly updating our processes in order to create more useful and higher quality products to better serve your needs.

BitMover is an innovative company. While other high-tech companies have taken the more common route of using venture capital to fund quick growth for a quick return, BitMover has been quietly building a strong foundation for long term stability and sustainable growth.

Our business model is quite unusual and we view it as part of our competitive advantage.

BitMover emphasizes quality and support. We have been successful by providing excellent support to our customers. We don't sell our product unless we know we can support it. Our philosophy is to build quality into our products. We do not ship software that we know is broken. All companies say these things, but in our case there is greater pressure to make good on these promises. Our products are infrastructure products, we know that if they stop working so do you. Hence our commitment to testing and a higher standard of engineering.

BitMover hires the best people possible.