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 the customer list. 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 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 - to be phased out in bk-5.0)
• 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 or Intel with 64bit extensions)
• MacOS X on PPC and x86
• NetBSD 1.6 on x86 (other releases upon request)
• OpenBSD 3.6 on x86 (other releases upon request)
• SCO OpenServer Release 5 on x86
• Solaris 5.6 and later on SPARC
• Solaris 5.7 and later on x86
• Windows 2000
• Windows 2003 server
• Windows XP
• Windows 2008 server
• Windows Vista

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.

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. Our engineers typically have more than 16 years of industry experience, are experts in their fields, and have shipped multiple successful products in their careers. We provide an exciting work environment, challenging problems, and excellent compensation and benefits. Come work with us, we are always looking for people who want to work hard and make a difference.

BitMover is here for the long haul. As a private company we make our decisions with a long term view. Instead of trying to make our next quarter financial results look good we are trying to build great products for you, products that help you be more successful in the marketplace. We view the products we are building as part of the foundation for your company and we take that seriously. Our products have built in redundancy and safety features to help your company keep functioning no matter what happens.

BitMover is a privately held corporation and is self-supporting through sales of our main product, BitKeeper. We're profitable and we are looking for more talented people to grow our company.

Our products are unique. They answer real needs and provide solutions to tough problems in today's marketplace. Unlike many of the companies from the dot com bubble, our products are infrastructure products which are critical to the development process. As long as there are engineers working on software, hardware, web, and/or document development, there will be a need for the tools that we develop. Our customers range from small specialized design houses to Fortune 100 companies.

Founders

• Larry McVoy
  Mr. McVoy has over nineteen years of experience in the computer industry. He has worked at Sun Microsystems, SGI, Cobalt Microserver, and Google. He is the designer of TeamWare, Sun's source management product. Solaris has been developed exclusively under TeamWare. Mr. McVoy is also an expert in high performance computer and networking architectures. He has published numerous technical papers and made many technical and marketing presentations on operating systems, clustering, networking, and performance issues. His paper on LMbench received the best paper award in the January 1995 Usenix. Mr. McVoy has made key contributions to many high performance products, including Sun's UFS filesystem, SCSI controllers, 100Mbit ethernet, VLANs, SparcCluster, SGI's Bulk Data Service (BDS), and MDBM. Mr. McVoy holds a MSCS and BSCS from the University of Wisconsin-Madison.

• Beth Van Eman
  Ms. Van Eman has over eighteen years of experience in the computer industry. She has worked in software operations at several startups, with a long stay at MIPS and then SGI. She was responsible for software configuration management and release at SGI. Ms. Van Eman holds a BA in Economics from the University of California Santa Cruz.

• Rick Smith
  Mr. Smith has over twenty-three years of industry experience, specializing in distributed source management since 1992. He is recognized as the world's foremost expert on changeset engines and revision control weave based storage. Mr. Smith holds BSEE/MSEE degrees from CMU and was employed by HP for 16 years, before leaving to form a consulting company

News

2009-01-02 BitMover Announces Record Year for Revenue
2009-01-02 Bitmover Employees Give Back to the Community
2008-10-03 BitMover releases BitKeeper 4.2
2007-09-21 BitMover releases BitKeeper 4.1
2007-01-18 BitMover Employees Embrace the Holiday Spirit
2006-10-11 BitMover Introduces Open Source L Programming Language
2006-07-28 BitMover releases BitKeeper 4.0
2006-04-27 BitMover CEO: Silicon Valley Needs Sun
2006-04-25 BitMover Expanding North American Operations
2005-11-15 BitMover Announces Open Source Awards Program
2005-11-08 BitMover Announces Seventh Consecutive Quarter of Record Revenue
2005-08-31 BitMover Achieves Record Growth in Second Quarter
2005-06-15 Maxtor Chooses BitKeeper For Software Configuration Management
2005-06-08 BitMover Releases BitKeeper 3.2.4
2005-06-01 BitMover Announces BitKeeper to CVS Converter
2005-04-05 BitMover announces accelerated commercial development strategy and migration plan for Open Source users
2005-03-17 BitMover Announces Open Source Client for BitKeeper SCM System
2004-05-12 NewsForge: BitKeeper after the storm - Part 2
2004-05-11 NewsForge: BitKeeper after the storm - Part 1
2004-03-18 BitKeeper wins Software Development Magazine Productivity Award
2004-03-17 BitKeeper Helps Double Pace of Linux Development
2003-11-10 BitKeeper Detects First Known Linux Security Breach
2003-01-27 LinuxWorld: Larry McVoy on BitKeeper, kernel development, Linus Torvalds & Bruce Perens
2002-05-28 Kernel Trap: Interview: Larry McVoy
2001-09-01 Software Expert: Balancing act for SCM (pdf)
2001-04-02 Linux Weekly News writeup of the Linux Kernel Summit, April 2001
2000-05-11 Linux Weekly News May 2000 News
2000-04-00 Linux Magazine April 2000 article
1999-04-01 Linux Weekly News 1999 Feature
1998-10-15 Slashdot

BitMover, BitKeeper, the BitMover business model, and/or BitMover's founders have been written about in the following books:

• Under the Radar: How Red Hat Changed the Software Business and Took Microsoft By Surprise by Robert Young and Wendy Goldman Rohm
• Open Source: The Unauthorized White Papers by Donald K. Rosenberg
• Rebel Code: Linux and the Open Source Revolution by Glyn Moody
• Free for All: How LINUX and the Free Software Movement Undercut the High-Tech Titans by Peter Wayner

Trademarks

The following are trademarks and/or salesmarks of BitMover, Inc.

BitKeeper, BitMover, BK/Free, BK/Basic, BK/Pro, BK/Essentials, BK/Premier, BK/Enterprise, BK/Web, BK/DB, BK/Bugs, BugManager, Line of development, Delta Development Model.

Contact Us

If you are interested in purchasing our products: try sales@bitmover.com or call us at 888-401-8808 and press 2 for sales.

If you need support: try support@bitmover.com or call us at 408-370-9911 and press 3 for support.

If you are interested in working on our products, please see our jobs section.

BitMover, Inc.
Suite 132
300 Orchard City Drive
Campbell, CA 95008

Tel: +1-408-370-9911 (international and California)
Tel: 888-401-8808 (toll free in the US & Canada)
Fax: 408-370-0626

Business hours are Monday to Friday, 9AM to 5PM PST.

Jobs

BitMover is a profitable, employee-owned Silicon Valley company that is experiencing rapid growth. Our customers range from fast growing startups to the Fortune 50.

Benefits of working at BitMover include:

• A fast-paced, challenging, and fun work environment
• Management with a clue (engineers rather than MBA's)
• Smart co-workers
• Competitive salaries
• Comprehensive health benefits package
• Excellent 401K program
• Profit sharing

Our work has resulted in significant advances in the state of the art. BitMover is the company that showed the world the value of changesets. BitKeeper has been documented to more than double the pace of development.

Our products have paid off for our customers. We have enterprise customers who save more than $1,000,000 per year by using BitKeeper.

BitMover is based in the Silicon Valley area with offices at the historic Water Tower Plaza in Campbell. The building offers:

• A VTA light-rail stop in front
• In-house pub
• Walking distance to downtown Campbell restaurants and shops
• Close to Los Gatos Creek Trail

BitMover is committed to creating a diverse environment and is proud to be an equal opportunity employer.

Windows programmer

We need more Windows systems programmers. The ideal candidates would have started on Unix and migrated to Windows to do systems programming.

Required background

• In depth knowledge of Windows file systems: NTFS, Fat32, network, mapped, subst, locking, etc
• In depth knowledge of Windows system level interfaces: sockets, file handles, processes
• Minimum of 3 years full-time experience programming Windows at the system level
• Expert C programmer with at least 5 years industry level experience
• Experience manipulating the registry
• .NET and Visual Studio experience
• Self-motivated self-starter with low management overhead
• Ability to think in "pictures" and implement to a "picture"
• BS in engineering, MS preferred
• Excellent references

Desired background

• Experience with cygwin and/or mingw
• Experience with make/gcc/gdb
• COM and ATL expertise
• SCC DLL programming
• Shellx programming
• Java/Eclipse/NetBeans experience
• Visual SourceSafe expertise
• Experience porting to many systems
• Bourne shell scripting
• diff, crypto, networking
• lex/yacc (aka flex/bison)
• HTML coding
• Troff/Latex/perlpod or some other simple markup language
• Wikis

Sales engineer

We are looking for a highly motivated sales engineer who will serve as a technical interface in sales opportunities.

The sales engineer will provide product demonstrations, address technical questions, and actively engage engineers and architects that are evaluating the BitKeeper suite of products. Sales engagements can range from on-site customer demonstrations to meetings over Webex. Since BitKeeper is a highly technical sell dealing directly with developers, a background in software development and experience with developer tools is desirable.

Required background

• At least 2 years of experience in a technical sales or sales engineering role
• Experience with software product demonstrations
• Experience with SCM solutions (e.g. CVS, Perforce, SVN)
• Versed in UNIX
• Proactive and motivated in following up with sales opportunities
• Good communication skills
• BS in engineering

Desired background

• Background in software development
• Experience coding in C or C++
• Experience with scripting languages (shell, perl)
• Good knowledge of at least one major SCM tool

Web Programmer

We are looking for an experienced programmer who is also an HTML wizard.

You need to understand HTML and CSS and one or more of PHP, Zope, templates, and Wikis. You need to be capable of creating by hand the output produced by PHP, Zope, or other content management systems. If you are a programmer who is enough of an artist to create good looking HTML by hand, you are a great match. If you are a programmer who would like to produce a small, fast templating system that could produce that same HTML, you are perfect. And if you think systems like PHP and Zope are too slow by at least a factor of 10, that is icing on the cake, come work here, you're perfect.

Your duties will include working on our web-based infrastructure. You will have a free hand to design and build much of the BitKeeper web-based user interface. The BK/Web interface on bkbits.net is where you could start (and as you can see it could use your help).

Required background

• Solid C programmer with at least 5 years industry-level experience
• Competent in low-level socket programming
• Experience with the HTTP protocol at the socket level
• Solid HTML and CSS skills
• Javascript experience
• Experience in Wikis; ideally you have written one
• Experience in markup languages such as Wiki, groff, latex, or perldoc
• Experience interfacing with database engines
• Self-motivated self-starter with low management overhead
• Ability to think in "pictures" and implement to a "picture"
• BS in engineering (MS preferred)
• Excellent references

Desired background

• Ajax programming
• Bourne shell scripting
• lex/yacc (aka flex/bison)
• Experience porting to many systems
• Windows experience
• GIMP or Photoshop tinkering for logos would be a plus

Technical Support

Our rapid growth has opened up new positions in the technical customer support area. The successful candidates for this position will be technical, friendly, and patient. We have a broad range of customers and you will need to be able to shift gears and handle everyone from brand new BitKeeper users to experienced users with deeper technical problems. That said, our customers tend to be smart and the support issues tend towards the deeper end rather than "are you sure the computer is on?"

BitMover has a stated goal of driving the product towards zero support and you could be instrumental in making that happen. Rather than answering the same question over and over, the your role would be to help evolve the product so that the question goes away.

Required background

• Industry experience with customer support
• In-depth knowledge of BitKeeper (preferred) or other source management systems
• Shell scripting ability; you will use this to write test cases to demonstrate customer problems, write triggers to implement customer processes, etc.
• A desire to help people
• Excellent references

Project Manager

We are looking for someone who is good at balancing engineering problems and business goals against engineering resources. The caliber of the developers here is high, the pace of development is fast, and the problems being solved require a ring leader who can keep people focused.

The ideal candidate would be someone who can understand the company goals and the day-to-day problems facing engineering, and optimize over the human resources available to get as much quality work done as possible. If you can do that and keep everyone smiling we want you.

Responsibilities include

• Manage a partially distributed team of developers
• Help develop product schedules and requirements
• Understand product release goals
• Drive engineering toward release goals
• Prioritize engineering goals and tasks

Required background

• 5 years management experience in the software industry
• Proven track record of delivering products on time and on budget
• Excellent references

Desired background

• Experience with distributed teams

Systems programmers

We always have openings for senior systems programmers. Duties will include the design and development of BitKeeper, the BitKeeper bug database, and/or other products produced at BitMover.

If you like C more than C++, small more than big, simple more than complex, products more than the latest buzzwords, you are the sort of person we want.

Required background

• Expert C programmer with at least 5 years industry-level experience
• Expert in low-level socket programming
• Experience with the SMTP and HTTP protocols at the socket level
• Expert Bourne shell scripting
• lex/yacc (aka flex/bison)
• make/gcc/gdb
• Self-motivated self-starter with low management overhead
• Ability to think in "pictures" and implement to a "picture"
• BS in engineering, MS preferred
• Excellent references

Desired background

• Experience porting to many systems
• diff, crypto, networking
• Windows experience
• HTML coding
• Troff/Latex/perlpod or some other simple markup language
• Wikis

Graphics/Web Designer

We are looking for an expert web designer to come in and revamp our website look and feel. We could also use your help revamping our web interface, both at the project level (BK/Web) and the hosting infrastructure (BK/Bits) on bkbits.net. For the right person, this could be a long-term position but we are open to working with someone on a contract basis.

What we need you to do:

• Redo our website to give it a more corporate look
• Redo and expand the test-drive section of the website
• Rework the graphics on our web pages
• Redo all the icons used in the BitKeeper GUIs
• Work on the web interface to our bug database

Required background

• Hand-coding of HTML using CSS
• Proficiency in Javascript
• Experience with content management systems such as PHP, Zope, etc.
• Excellent references

Desired background

• Programming experience in C, perl, and/or awk
• Technical writing

It would be great if you had the artistic skills to do this sort of thing and you liked working on web sites and web infrastructure. Take a look at bkbits.net and poke around. That site is looking for someone to polish it up and make it look more professional. It needs better indices, organization, listings of active projects, users, etc.

Please take a look at our Web Programmer listing as well.

Systems Administrator

We have filled this position but in the long tradition of system administrators at BitMover the current holder of this position is doing more programming than administration so we are looking for a replacement.

Care and feeding of an internal network (~6 subnets, mostly switched 100base-T) including a build cluster of approximately 30 hosts. Network is connected to the Internet via dual T1 lines. The network includes a VPN to multiple remote developers.

Operating systems include AIX, FreeBSD (2.x - 5.x), HPUX (10 and 11), IRIX, Linux (on everything from StrongARM to Itanium), MacOS X, NetBSD, OpenBSD, SCO, Solaris (SPARC and x86), Tru64, VMware and Windows (2K, 2003, XP, Vista). In addition to the build cluster there are approximately 50 developer and server machines, which are typically Linux or Windows.

Duties include some or all of:

• Maintaining the network, DNS, etc.
• Maintaining the apache-based web servers
• Building new PC machines as required
• Replacing system parts as required (PC and older SCSI-based systems)
• Coding infrastructure tools as needed

Required background

• Experience with BIND, Mailman, Postfix (and sendmail, but more emphasis on Postfix)
• Experience administering both Unix and Windows (SMB, for example)
• Expert-level Bourne shell scripting
• Good Perl skills (preferably old-school perl 4)
• Enough C skills to write a basic more(1)
• BS in engineering
• At least 3 years industry experience (post-college)
• Self-motivated self-starter with low management overhead
• Excellent references

Desired background

• Source management systems (BK, CVS, Perforce, etc.)
• HTML (including CSS)
• tcl/tk scripting
• backuppc.sourceforge.net
• www.ipcop.org

Reasons to work here

We realize that the caliber of people we are looking for is in high demand, so why work at BitMover?

• Excellent products. BitKeeper is the industry's only peer-to-peer collaborative development tool. There is no better product on the market that solves globally distributed development, merging, and work flow.
• High-caliber people. Our staff consists of some of the best people in the world. We work hard and demand exceptional results from each other. At the same time, we are friendly, we have fun, and we respect each other.
• Interesting problems. We produce cutting-edge products. To do that, we are tackling problems that are not easy to solve. We work in many different areas such as systems design, file systems, networking, cryptography, web, databases, programming languages, compression, synchronization and GUI tools.
• Customer satisfaction. We strongly believe in taking care of our customers and the results speak for themselves. Most of our customers lease our products and we have a 99% renewal rate. Our customer base includes companies ranging from startups to the Fortune 50.
• Company Growth. Our revenues have been doubling year over year and our projections indicate that we will continue at this rate over the next three years.
• Quality. We never sacrifice quality to meet the schedule. We have the resources to take the time to get it right.
• Company stability. Unlike many private companies, BitMover is financially sound. We are profitable, do not rely on outside investment, and have no debt.

Thank you for your consideration and let us know if you have questions.

Applying

Thanks for considering working here, we are looking forward to speaking with you.

Please email a plain text resume and a cover letter to: jobs@bitmover.com and tell us where you think you would fit best.

If at all possible, please do not send Word documents since they sometimes have trouble getting through the spam filter. Just use Save As->text in Word and send us that.

Note: BitMover does not accept unsolicited agency resumes and will not pay fees to any third party agency or firm that does not have a signed recruiter agreement in place.

Please contact BitMover at jobs@bitmover.com or 408-370-9911 to refer a candidate or to get more information on the referral program.

BitMover is committed to creating a diverse environment and is proud to be an equal opportunity employer.

Support

BitMover provides world class support for all of our products. We pride ourselves on being responsive and helpful to our customers.

Normal bug fixing, small enhancements, bug fix releases, and assistance during initial deployment are all part of all of our support packages. For more specific support options, click on the purchase model your company chose. If you don't know what that is, it is probably the leased seats option.

If you have extended support needs, our professional services group is here help you.

All users may, and should, submit bugs using bk sendbug. Please make sure you are running a recent release before filing a bug.

Leased seats

If your company has leased BitKeeper then support is automatically included. Support for leased seats includes all upgrades, both bug fixes and major releases, as well as normal telephone and email support.

Please submit bug reports and/or RFEs (request for enhancements) using bk sendbug; if the bug is not in our bug database it may not get fixed. Please make sure you are running a recent release before filing a bug.

Send mail to support@bitmover.com to inquire about support issues.

Purchased seats

If your company has purchased a specific version of BitKeeper, support is included for the first year. After the first year, your company needs to purchase a yearly support contract to continue to get full technical support and product upgrades and bugfixes.

Please submit bug reports and/or RFEs (request for enhancements) using bk sendbug; if the bug is not in our bug database it may not get fixed. Please make sure you are running a recent release before filing a bug.

Send mail to support@bitmover.com to inquire about support issues.

Professional services

Our professional services group is here to help you. Some of the services we've provided in the past:

• Extended deployment assistance
• Implementing workflow using BitKeeper
• Custom development of new functionality
• Site specific trigger implementations
• Offsite hosting

Contact us for availability and rate information.

Bug database This section is a hyper link to here.

Release history

BitMover is continually updating and improving its products, we strive to make our products backward compatible and stable while providing new functionality and product enhancements.

The following commands are useful for upgrading:

# Check to see if there is an upgrade available $ bk upgrade -c # Upgrade to latest $ bk upgrade # Look to see what architectures are available $ bk upgrade -a

Supported releases

Date	Release name
2008/02/02	bk-4.3
2008/10/13	bk-4.2
2008/06/04	bk-4.1.2
2008/02/13	bk-4.1.1
2007/09/20	bk-4.1
2006/12/17	bk-4.0.2
2006/10/17	bk-4.0.1
2006/08/17	bk-4.0

Older releases

Date	Release name
2006/05/15	bk-3.2.8
2005/11/16	bk-3.2.7
2005/09/23	bk-3.2.6
2005/08/04	bk-3.2.5
2005/05/14	bk-3.2.4
2004/08/13	bk-3.2.3
2004/06/23	bk-3.2.2
2004/05/28	bk-3.2.1
2004/05/19	bk-3.2.0
2003/12/22	bk-3.0.4
2003/10/22	bk-3.0.3
2003/08/13	bk-3.0.2
2003/01/15	bk-3.0.1
2002/10/10	bk-3.0
2002/03/14	bk-2.1.5
2002/02/05	bk-2.1.4
2001/11/16	bk-2.0.5
2001/11/12	bk-2.0.4
2001/11/09	bk-2.1.3
2001/11/04	bk-2.1.2
2001/10/30	bk-2.0.3
2001/10/23	bk-2.1.1
2001/10/19	bk-2.1.0
2001/10/16	bk-2.0.1

Mailing lists

• BitKeeper
  There are BitKeeper mailing lists maintained on BitMover.
  General discussion: bitkeeper-users
  Announcements only: bitkeeper-announce
  Note: "bitkeeper-announce" includes "bitkeeper-users", so if you want to be on both, just subscribe to "bitkeeper-users".

  The threaded archives are available as bitkeeper-users and bitkeeper-announce.

Privacy Policy

At BitMover, we strive to develop innovative products and services to better serve our users. We recognize that privacy is an important issue, so we design and operate our products and services with the protection of your privacy in mind. This Privacy Policy outlines the types of personal information we gather when you use our products and services, as well as some of the steps we take to safeguard it.

The following principles apply to the personally identifying information we ask for and that you provide. "Personally identifying information" is information that individually identifies you, such as your name, physical address or email address. The following policies are only in effect for the BitKeeper configuration management system, the BK/DB database system, the web pages, and opt-in discussion and/or announcement lists owned and operated by BitMover, Inc.

What don't you do with the information you collect?

We do not, and will not, gift, rent, sell or resell your private information to other companies or individuals.

What information are you collecting and how are you collecting it?

We may collect information from users when they use our products. This information may include your email address, host/domain name, user name, and/or other information which uniquely identifies you to us. What we may collect varies across our products and/or services:

• BitKeeper: When you install BitKeeper we may send an installation log message.
  When you use BitKeeper to create changes we may send a log message to bitkeeper.com. The log message contains only enough information to record that you have used BitKeeper to make a change. It does not contain any checkin comments, pathnames, or anything else which could be used to determine what you are doing with BitKeeper.
• BK/DB: Any information collection is identical to that collected by the BitKeeper configuration management system.

What do you do with the information you collect?

What we may do with your information varies across our products and/or services:

• BitKeeper: We use the installation log messages to determine which platforms are popular and which may be safely obsoleted.
  The log messages sent back are used to count seats for billing purposes. Because BitKeeper is a distributed system and because we never want licensing to get in the way of your productivity, we use this method to centralize the seat counting process. This process ensures that you are billed for what you use and no more, resulting in lower costs to you. While some people have concerns about this system, all of our customers, including many Fortune 50 companies, use this model and have verified that it does not include any intellectual property leak.
• BK/DB: Any information collection is identical to that collected by the BitKeeper configuration management system.
• Opt-in mailing lists: Our mailing lists are managed by the mailman mailing list software. Any information you may post to those lists is by design available to anyone who wishes to see it.

Policy changes

Please note this Privacy Policy may change from time to time. We expect most such changes to be minor. Regardless, we will post those changes here and, if the changes are significant, we will also provide a more prominent notice to the bitkeeper-announce discussion list.

If you have any additional questions, please feel free to contact us any time at privacy@bitmover.com.

Documentation

This section contains links to different kinds of documentation for BitKeeper. It's a constant work in progress as we evolve the documentation.

The reference material is included with BitKeeper; it may be read, searched, and/or browsed by using bk helptool [topic]. The material included with BitKeeper is more likely to be up to date than this web site.

The documentation is divided into reference material, a printable quick reference guide, some FAQs, some Howtos, and a user guide. The user guide is in a different location, clicking on the user guide link on the left will take you there.

Quick reference guide

A small summary of the commonly used BitKeeper commands, suitable for printing, is available as Postscript or PDF

Reference manual

All BitKeeper commands are documented with included online documentation. The reference pages are available at the command line

bk help topic

bk helptool

Command Comparisons

The following command comparisons documentation is a translation system of sorts between other product's commands and BitKeeper commands.

Thus far we have documentation for CVS only.

CVS to BK This section is a hyper link to here.

Bug Database

BitMover's BugManager can be found at

http://db.bitkeeper.com

There are four defined states at this time:

• Open - any bug that is open and not assigned; this is a bug's initial state
• Assigned - any open bug that has been assigned an owner
• Fixed - any bug that has been fixed and closed
• Closed - any bug that will not be fixed and has been closed

Submitting Bugs

If you have found a bug in BitKeeper, you can submit it via the command line or on the web.

To submit BitKeper bugs via the command line, do

bk sendbug

To submit a bug using the web, go to the bug database page:

http://db.bitkeeper.com

To submit,

• click on the "Submit bug" tab
• fill out the form and click "Submit"

Querying Bugs

To query bugs go to

http://db.bitkeeper.com

Specific Queries
To list bugs that match specific criteria:

• click on the ¨Simple Query¨ or ¨Advanced Query¨ tab.
• fill in the query form with as much specific information as you can
• click "Send Query"

Sorting Lists
When you are looking at a list of bugs, you may sort that list by clicking on the top heading of the column for the field on which you would like the data sorted.

Viewing Bugs

From A List
If you have a list of bugs and would like to view a particular one, click on the hyperlinked BugID number.

If you have an ID number
If you know the number of the bug you wish to view,

• go to http://db.bitkeeper.com
• Click on the Simple Query tab
• Cut and paste the ID number into the ID field
• Click Run Query

Updating Bugs

To update or change a bug's state, first view the bug using one of the methods in the Viewing Bugs section.

Any field that allows updates can be modified. Once fields are modified, click on Record changes.

You will be prompted to verify your updates. Once verified, the bug will be updated with your changes.

User guide This section is a hyper link to here.

FAQS

General usage

• What are the SCCS directories in my repository all about?
  That's where all the metadata for the revision control is stored. Do not remove any piece of the SCCS directories. People have been known to remove part or all of the contents of the SCCS directories which has serious consequences for BitKeeper. If you do remove some or all of the SCCS files these repositories can probably be restored. Please contact support@bitmover.com for help.

• Does BitKeeper have support for versioning directories?
  Bitkeeper does not version directories directly, it version controls files. Another way to say it is that BitKeeper version controls file "objects". The objects have several attributes including contents, permissions, and pathnames. When instantiating any version of the repository, all directories needed in order to place an object (file) where it wants to be are created automatically. The only limitation is that BitKeeper currently has no way to version control an empty directory.

• I'd like to be able to create, move and delete files and have that versioned along with the rest of the files. Does that capability exist?
  BitKeeper tracks all attributes associated with a file; path names are one of those attributes. All attributes are tracked in every delta, not just a tagged changeset. This means when you rollback or undo a change set, renamed files will be automatically move back to their previous locations.
  See also bk helptool mv.

• How can I turn off keyword expansion, that is: [ Documentation expansion ] ?
  

  bk admin -FSCCS foo.c	# OR
  bk -r admin -FSCCS	# Does it on every file

  
  If you want to understand more about this, bk helptool keywords will explain which keywords get expanded when, and bk helptool admin tells you how to shut off SCCS keyword expansion.

• Is there any way (other than putting something in the triggers) to tell a particular repository that it should always try to do the equivalent of 'newgrp bk' every time? (I have the repository owned by group bk)
  If you like to set the sgid bit on directories, you need to specify the symbolic mode. This is a safety enhancement of chmod.

  find . -type d | xargs chmod u=rwx,g=rwx+s,o=rx

  should do the trick.

• I am in the EST timezone with daylight savings time and dates are showing up wrong in the revtool. The changesets reflect the time accurately but the tool is displaying the dates as if they were UTC. What's up with the timezones?
  Yes, the times in revtool are in UTC. The reason for this is that when projects have members in different timezones, the dates at the bottom start becoming out of sequence when members to the east do commits before you do. For example, if we display dates in local time and someone in a timezone where it is the next day does a commit before you, then you will see the something like:

  1/16 1/15 1/17 2001 2001 2001

  One of our customers found the out-of-sequence dates irritating and asked that we display the dates in UTC.

Making changes

• How do I retrieve and put packages back into BitKeeper?
  bk clone retrieves a copy of a package, bk citool checks the files into the package and creates a changeset, and bk push puts your changes back into the parent package repository.

• How do I export a clear-text version of the repository as of some version?

  bk export -tplain [-r<rev>] /tmp/snapshot

• After doing a ``bk citool'' the result is only a pending change. I then have to do a ``bk commit'' Why require two steps?
  You must add a comment to the ChangeSet file entry in citool, which at some point in the future, you will probably find very useful -- you should describe the reason for the changeset. Without a comment for ChangeSet, citool will not do a "commit" for you, the file you checkin will be left in pending state.

• Let's say I have a repository in /home/bkdev. If I simply move that directory to /home/project/bkdev, will that muck up anything that bk uses to keep track of project info, e.g. for use with the open logging system? If it does muck with things, what is the 'safe' way to move or rename a bk repository?
  Moving a repository is a safe operation. Just make sure that any child repositories' parent pointers are reset:

  bk parent <new-parent>

Viewing changes

• How can I find out what files have been modified and what the changes are?
  You can either use bk citool or a combination of bk sfiles and bk diffs.

• How do I view differences between file revisions?
  The main file browser is revtool. If you want to see changes between two checked in versions, run:

  bk revtool filename

  and a graphical viewer will appear. You can double click (left mouse) on any version and an annotated version will appear in the bottom window. To see differences between any two versions, left click on the earlier version and right click on the later.

  Another frequent request is to see the differences between the checked in version and a working version that has been modified. To do this, run:

  bk difftool filename

  and a side-by-side viewer will appear. You can even use difftool on files that are not checked in at all by specifying those file names.

• How can I view overall history/status? That is, how can I piece together what has happened in a repository -- when it was cloned, what happened since the clone, etc.

  bk revtool

  will browse the entire package. If you select one or more revisions, you can click "View changesets" to get detailed information about the files changed in that changeset. See bk help revtool for more information.

• How do I view revisions of a package and individual file revisions in that labeled package?
  Revisions of a file are best viewed with bk revtool. This is a GUI that shows context differences. In the top window is a graph of the file's history. Left click and right click on two versions of the file to see the context diffs. To see side-by-side full file diffs, click on the "diff tool" button and a new window will display that. If no filename argument is given to revtool, it displays the entire package's history.
  Revisions of a package can also be viewed using bk csettool. You'll need a revision number as an argument to csettool; bk changes or bk revtool will give you a revision number. Csettool is used to view the detailed information about the specified changeset[s]. The tool displays the list of changes in each changeset, the ChangeSet history, and (optionally) the differences found in each file contained in each changeset.
  To see the changes for a particular file, click on the file name the top left window and you will see:
  * the number of diffs in the light blue, middle status window
  * the old version of the file in the lower left window
  * the new version of the file in the lower right window
  * the ChangeSet's comments followed by the delta's comments in the upper right window
  Use the space bar to move between diffs and files. Each time you hit the space bar, the next diff is brought into view. If you are on the last diff, the tool moves to the next file. The Next (>>) buttons and Previous (<<) buttons in the upper left corner will also allow you to browse the files and diffs.

• Is there any way to diff two committed and tagged versions of the repository
  Yes, there is a way. Use:
  

  bk export -tpatch -rtag1,tag2 | more

File operations

• What is the best method for adding new files to a BitKeeper package?
  If you are adding a small number of files, the easiest thing to do is

  bk new file

  If you are creating a new package, and you have an existing set of files, run:

  bk setup new_package bk import -tplain files new_package

  which will import all files into the new package. This method can only be used once, when the package is created.

  If you have a large number of files to add to an existing package, the easiest way is to copy the files into the package, generate a list of the files, edit the list to make sure there are no unwanted files (such as object files from an earlier build), and then create the files from the list. For example:
  

  cd new_package
  mkdir new_files
  cd new_files
  cp -rp ~/files_to_import .
  bk sfiles -x . > /tmp/LIST
  vi /tmp/LIST	# remove any you don't want
  bk new - < /tmp/LIST

  
  
• What is the best method for deleting files from a BitKeeper package?
  The command bk rm file(s) will remove a file(s) from the BitKeeper package. Because BitKeeper remembers everything, this actually renames the file to .del-file. All future BitKeeper operations ignore the file unless you name it explicitly, but it still exists in the package and will still be propagated by resync/pull/push.
  If there is a file that you really want to not be in the tree, you have to do this:

  bk gone `bk prs -hr+ -d:KEY: file` rm file SCCS/s.file

  The gone command records the fact that the file is really gone and tells BitKeeper to not complain when it can't find it.

  Can I simply do a 'bk ignore deleted/' so that subsequent clones won't get the deleted directory?
  The short answer is no. The most important points to note are:
  * bk gone takes a root key as argument, not a file name or directory name.
  * bk gone does not actually remove a file, it just informs BitKeeper that the file (which is associated with the specified root key) is physically deleted. The lack of a bk command to physically remove a file is deliberate, we do not want to encourage this action, since it results in a lack of reproducibility.

• What does BitKeeper do with file permissions and how can I change them?
  BitKeeper preserves all file permissions as they were originally set in the first established tree, unless you specifically change them with the bk chmod command.

Multiple file operations

• How do I check in lots of files from the command line?

  bk sfiles -U -c | bk ci -yyour_comments -

• How do I modify every file in the tree in one shot for testing?

  bk sfiles -g -U| while read x; do echo $x; echo "foobar" >> $x; done

• How would I ``bk get'' all *.pm files in all subdirectories?
  Try this:

  bk -R sfiles -g | grep '\.pm$' | bk get -

• How do I find all bad writable files?

  bk -r check -w

  Typical usage:

  bk -r check -w | bk -R edit -g - bk -r check -w | bk -R xargs whatever

Merges

• Is there a way to make the diffs during merge (i.e., dr[m], dl[m]) output a unified context diff instead of the old style diff?
  Yes, you may call an external tool to merge changes. When in the resolver, you can say:

  file.c>> !<command>

  then <command> will be run with the following environment variables set:

  BK_LOCAL - pathname of a temp file containing the local version
  BK_GCA - file containing the common ancestor
  BK_REMOTE - pathname of a temp file containing the remote version
  BK_MERGE - pathname where the merged content should be placed
  So you could make a little shell script:

  #!/bin/sh if [ "X$PAGER" = X ]; then PAGER=more; fi exec bk diff -u $BK_REMOTE $BK_LOCAL | $PAGER

  call that ``udiff'' and then do:

  file.c>> !udiff

  and you're all set.

• I would like to be able to do an manual merge ('e') without the preceding automerge. Is this possible?
  Yes. The same technique as above would do it. That is, the command run would be the editor you want run.

Import

• I am tracking some vendor sources which I have put into a BK repository using bk import. I tagged it after the import so I could get it back out, etc. if I need to. I have got a new release and need to put it into the repository and will tag it with the new release, but how do I do this? It seems that bk import only works once (the first time) on a new bk repository.
  Assuming you know how to generate patches, and have a patch, you can:

  bk clone -rvendor_rel_1 tree import_tree bk import -tpatch import_tree

Undoing work

• How do I undo or back out changes?
  There are several ways to get back to an earlier version:
  a) When debugging a problem, you may want to base a bug fix on an earlier release. First you'll want to find the correct version of the package (you can say bk revtool without a file name argument to browse the package, or say bk changes to see the changes from the command line).
  Once you have the version, say:

  bk clone -r<version> master bugfix

  Then make the changes in bugfix. Whether you merge them back into master or not is a policy decision; most companies create a bug fix tree (or series of them) and engineers clone from "Project-1.0" and push back into that.

  b) If a change came into your tree and more changes are also there on top of the earlier change, you cannot use undo to get rid of the change. You can "exclude" that change by running

  bk cset -x<version>

  which will create a change that removes the effects of the change specified by <vers> (and yes, you can later bk cset -x the change that excluded the first change and the first change will come back). This choice is by far the safest thing to do - no information is lost and you can change your mind later.

  c) If you pulled a change into your tree, and you are not ready that change yet, then you may be able to undo it. It has to be the most recent change or series of changes. To undo it, find the versions that you want to get rid of, make sure they are at the top of the graph, and run:

  bk undo -r<vers>,<vers>,<vers>

• How do I manually do an anti-delta on a single file?
  Very easily. All the bk cset -x does is recursively do a bk get -e -x on each of the deltas in each of the files which were part of the specified changeset.
  If all you wanted to do was undo the effect of the bk cset -x (or -i) on a single file, and that file was last modified by the cset, then you can just X out the -x like so:

  bk edit -x+ file

  if you want to have some weird fun, you can keep repeating that. All you are doing is manipulating the set deltas which make up the file contents.

• How do I remove changes from the last pull? Basically, I am looking for a 'bk undolast' kind of command'.

  bk unpull

Tags

• How do I label revisions of a package? And how do I then retrieve a certain package revision by label in case one labeled version works and the other does not?
  Labels are called "tags" in BitKeeper. To add a tag to the package, make sure you've checked in everything and created a changeset. You can use bk status to see what needs to be checked in and/or committed to a changeset. Tag the tree by typing:

  bk tag TagName

  The most recent changeset is now labeled, or tagged, with "TagName". If you didn't want to tag the most recent changeset, you can say

  bk tag -r<vers> TagName

  to add the name to any revision. You can now use this tag as an argument to clone, for example:

  bk clone -rbeta master beta

  which creates a repository called "beta" that has everything up to and including the "beta" changeset.

  A frequent problem is that you tag a changeset with "Done" and then discover you weren't really done. You can update the tag to the later changeset by running the bk tag Done command again.

• How do I view comments that have been written for specific files or a labeled package?
  For individual files, use bk prs filename. For a tagged changeset, use bk changes.

• Is there an easy way to find out what tags are in a tree and when they were created with what changesets, etc.?
  

  bk changes -t

  or

  bk -R prs -hr1.0.. -nd'$if(:TAG:){:DEFAULT:}' ChangeSet

Failure recovery

• What does BitKeeper do in the event of some failure? Will we have half-done work in BitKeeper?
  It depends on the failure. All of the common failures have been handled, but new users find new and wonderful ways to make BitKeeper fail. The most important thing to do if something goes wrong is to create a "tarball" of the repository before you try to figure out what went wrong. Suppose you had a cloned copy in your home directory named "my_work". If something goes wrong do this:

  cd tar czf BUG.tgz my_work

  That way, if you can't fix it, you have something that you can ask BitMover to unscramble. We've successfully unscrambled problems that were quite complicated and each time we do that, we put code into the system to make sure the problem doesn't come back. So please tell us about any problems you find.

  If the machine has a failure, do a bk -r check -a which will check the repository to make sure it's in a consistent state. If check reports errors, contact BitMover.

• How do I complete a failed pull? I did a pull and had files checked out and the pull didn't complete. I noticed that a PENDING directory was created. Is there a way for me to complete the resolve without making another network connection?
  The contents in the PENDING directory need to be rerun. The pending directory will have one or more patch files that have names made up of the data plus a sequence number. Find the latest PENDING file and then run takepatch and resolve on it. For example:

  bk takepatch -vvf PENDING/2000-09-19.01 bk resolve -a

• What's the best way to recover from the following type of error?

  docs/img/services/acct/top_back_bar.gif: 2 deltas docs/img/services/acp/titles/scheduled.gif: 2 deltas --------------------------------------------------------------------------- takepatch: saved entire patch in PENDING/2001-03-26.02 --------------------------------------------------------------------------- =================================== ERROR ==================================== takepatch: SCCS/s.ChangeSet is locked w/o writable gfile? takepatch: patch left in PENDING/2001-03-26.02 ============================================================================== 496746 bytes uncompressed to 1127864, 2.27X expansion

  If you are doing a push, go to the parent tree; if you are doing a pull, go to the client tree, and from that directory type:

  cd RESYNC; bk unlock -p ChangeSet

• Given the following situation, how do I continue the resolve?
  box ``A'' holds a clone of a repository
  box ``B'' is where I'm working
  I had a resolve going on box ``A'', in an rxvt on box going until box ``B'' crashed. Now when I try to run resolve I get:

  $ bk resolve Using boxB:0.0 as graphical display Verifying consistency of the RESYNC tree... ======================================================================= check: arch/ppc/kernel/pmac_pci.c is locked but not checked out, which usually means that a file was locked (via a "bk edit") and then removed without being unlocked. ======================================================================= {bk} {-r} {check} {-cR} failed. Resolve not even started. resolve: RESYNC directory left intact. =======================================================================

  Try this:

  cd to the RESYNC tree bk unlock -p arch/ppc/kernel/pmac_pci.c

  Alternatively, if you have not invested a lot of work in the resolve process, you can always do a bk abort and re-do the bk pull.

• I'm trying to do a fairly large clone remotely and because the connection appears quiet, the line is dropped and the clone then fails. What can I do to work around this?
  To keep the line alive, and thus the clone, open a second window and ping the repository every ten seconds or so.

• I accidentally deleted a SCCS/s.* file in my cloned repository. To continue working, I scp'ed it from the parent repository. Is this the correct fix? Is there a better way?
  That will always work as long as the parent is not ahead or behind where you were when you lost the file. If the parent is behind, you are out of luck. If the parent is ahead, then you can actually strip it backwards to make it match your environment.
  Remember that you can always run bk -r check -a to make sure BitKeeper is happy with the state of the repository.

• I have gotten myself into trouble by doing some part of the checkout, edit, commit operation as root. Now when I try to push, I get:

  bk push ----------------------- Sending the following csets ----------------------- 1.336 --------------------------------------------------------------------------- --------------------------------------------------------------------------- takepatch: saved entire patch in PENDING/2001-03-06.07 --------------------------------------------------------------------------- =================================== ERROR ==================================== takepatch: SCCS/s.ChangeSet is locked w/o writable gfile? takepatch: patch left in PENDING/2001-03-06.07 ==============================================================================

  What can I do about this?
  Try:

  bk -R unlock -p ChangeSet

Event triggers

• Can I get automatic email to individuals within a defined group whenever changes are checked in?
  Yes, this is done by using triggers, commands which run before or after a repository level command. In this case, you would want to set up a post-commit trigger. That is, in the BitKeeper/triggers/post-commit directory you would setup a shell script to send mail to those people you want to notify. Pre-triggers can be used to control events within a repository. For more information, see bk helptool triggers. But note that triggers are available only with the BK/Pro product.

• How difficult is it to pass user-specified environment variables to the triggers? For example, I want to be able to pass the environment variable MAILTO containing the email address of the user.
  It's easy. Use:

  bk pull -E/bk push -E

Configuration

• How do I automatically checkout files in Read-Write mode after I do a checkin? Add a checkout mode line to the BitKeeper/etc/config file, see bk help config-etc for more information.

  checkout: get checkout: edit [akushner]checkout: edit

  Make sure there is a space after the colon, i.e., ``checkout: edit'' and make sure the config file has been checked in.

  Another tip is that if you just alias vi='bk vi' then bk will check out the file in edit mode and then run vi on it. The BitMover development staff runs with this alias all of the time.

• bk citool always displays a long list of irrelevant files. Is there some way to hide these files?
  If there are files in your repository you won't ever want to check in, such as core, *.exe, etc., you should put them in the ``ignore'' list. You can either use the ``Ignore'' button in citool, or create your own ignore file. See bk helptool ignore for more information.

• Is there any way to specify the exact X11 font one wants?
  Yes. Here's an example from one of our users:

  # this font is *much* easier to read with the default X setup set gc(fixedFont) "-*-lucidatypewriter-medium-r-*-*-12-*-*-*-*-*-iso8859-1" set gc(fixedBoldFont) "-*-lucidatypewriter-bold-r-*-*-12-*-*-*-*-*-iso8859-1"

Error messages

• What does this message mean?

  Running resolve to apply new work... Check: found in ChangeSet but not found in repository:

  This means you may have deleted an sfile after having committed it to a changeset.

• Sometimes bk clean acts confused and responds with: <filename> writable but not edited What's going on?
  Just do a bk edit -g <your file> (this changes your file to edit status without overwriting your existing gfile) and then run bk citool again.

• What would cause Entire Repository locked by RESYNC error:

  Entire repository is locked by: RESYNC directory. Cannot do pull into locked repository.

  The RESYNC directory exists because a previous bk pull failed due to a conflict that hasn't yet been resolved. At the end of that pull, there should have been a message stating something like "pull failed due to unresolved conflict, run resolve".

  At this point, you have two options: if you want to resolve the previous conflict and continue with a new pull, you should run 'bk resolve' and then type 'e', fix the conflict, get out of the editor, and then type 'C' to commit the fix.
  Or, if you don't want to do the conflict resolution, you can do a 'bk abort' and that will get rid of the RESYNC directory, but you will eventually have to resolve the conflict in order to pull.

• What does this error message mean?

  getRegBody: Can't open bk-names.1 for writing get of SCCS/s.bk-names.1 failed, skipping it. getRegBody: Can't open bk-unpark.1 for writing get of SCCS/s.bk-unpark.1 failed, skipping it. getRegBody: Can't open bk-level.1 for writing

  
  It most likely means that your system has run out of inodes.

• Is there some way to get better information when debugging the logging process?

  bk _log -d

  will tell you what is going on.

• I am trying to push up to my repository and I get the following errors:

  Running resolved to apply new work .... ============================ sane: bad host name: "red-hat". BitKeeper wants fully qualified hostname. =========================== {bk}{-r}{check}{-cR} failed. Resolve not even started.

  Actually, the name of my computer IS red-hat. What can I do to get around this?
  BitKeeper requires fully-qualified DNS names in order to ensure we do not create BK keys that are not unique. A key looks like this:

  user@host.domain|src/foo.c|YYYYMMDDHHSS|12345

  and we use the user@host.domain part to know that we are not creating the same key twice to name two different things. So, instead of red-hat, your machine should be named red-hat.com. To verify the rename worked, use the bk gethost command. And in general, you can make sure BitKeeper is happy about this sort of thing by running the bk sane command.

Windows/NT

• We have some project files that must not have EOL conversions (DOS->UNIX) done on them. How can we ensure that these files have native EOLs preserved?
  

  bk admin -fEOLN_NATIVE filename

  should do the trick. This says to use the operating system's native end-of-line termination. On Windows, the gfile is generated with CRLF as EOL. On Unix, the gfile is generated with LF as EOL.

  Note: if you check the file back out on Unix, the file will have LF only.

BK/Web

• BK/Web is "missing" the most recent changeset in one repository here. That is, revtool shows 1.13 (a merge cset) as the last cset, and BK/Web in the same place showing a pre-merge version as the most recent one. 1.13 doesn't show in BK/Web anywhere.
  We do not show merge changesets in BK/Web if there is no content. We did this because the no content merges just take up space without showing you anything.

Linux

"How do I install BitKeeper?"

Point your browser to: http://www.bitkeeper.com/Products.Downloads.html
And follow the instructions.

"Do I have fill out the forms and wait for email every time I update BitKeeper?"

No, once you have the username and password for the download site, you may use that to access the download area any time you want to update BitKeeper.

bk clone bk://linux@linux.bkbits.net/linux-2.4 mylinux-2.4 bk clone bk://linux@linux.bkbits.net/linux-2.6 mylinux-2.6

You now have a copy of the Linux 2.4.x source tree in the directory ``mylinux-2.4'' and a copy of the Linux 2.6.x in the directory ``mylinux-2.6''.

"I cloned the tree, but all I see are directories. Where are all the files?"

BitKeeper does not automatically check-out files unless configured to do so. To get all your files, change directory into the top-level directory of your repository and run:

bk -r co

This will recursively descend each directory in the repository and check out every file read-only. Although it is not recommended, if you prefer to have all your files checked out read/write, run:

bk -r edit

This will increase the total number of administrative files in your repository which wastes disk space and can make other operations run slower, unnecessarily.

You may configure your repository to do auto-checkouts. For more information, see

bk help config-etc

"I want to make some changes, what do I do?"

For each file you want to edit, run:

bk edit filename

Do not change the write permissions of a checked out file directly. If you just change the file permissions of the checked out file to make it writable, bk will be put in an inconsistent state and will not let you check in your changes.

For a convenient shortcut, read through the editor help page, and follow the directions for making bk checkout files read/write before editing them:

bk help editor

"What is a changeset?"

A changeset is a grouping of one or more changes to one or more files. Each changeset has comments and revision numbers associated with it apart from the comments and revision numbers associated with the individual files.

"What's the difference between check in and commit?"

Changes to individual files are checked in. A commit groups checked in changes together in a changeset.

"How do I check in and commit my changes?"

You may use the command line or the graphical check-in tool to check in and commit changes. The graphical check-in tool is the preferred method because people make better comments when they can browse the changes.

Graphical
To use the graphical tool, run:

bk citool

The top window shows modified files and files not under revision control. The middle window is the comments window and the bottom window shows the diffs for a modified file and the contents of a new file.

Clicking on a file name will select it for making comments. When comments are made to a file, it is ready for inclusion into a changeset. If not creating a changeset, after all comments are made, click on the Quit button and save comments.

If you are ready to commit your changes to a changeset, select the ChangeSet file in the citool file list and add comments. By default, all files with comments and all extra files that have been chosen for inclusion will go into the changeset. You may toggle between including/excluding a file from a changeset by left-clicking on the icon to the left of the file name. Click on commit twice to commit the changes to a changeset.

Command Line
If you prefer a non-graphical check in tool, you can check in individual files with:

bk ci

And to group all currently checked in changes into a changeset, run:

bk commit

"When I check in, will my changes appear in the main repository?"

No! When you check in or commit your changes, only your local copy of the repository is altered. To update another repository, run:

bk push [remote_repository]

"I just checked in some changes and now the changed files are gone!"

By default, bk will not check out a file after checking it in. To check it back out, run:

bk co filename

If you would like bk to auto-checkout your files, you must configure the repository to be in checkout-get mode. To configure the repository to run in checkout-get mode, do the following:

bk edit BitKeeper/etc/config echo -e ``\\n[]checkout:get'' >> BitKeeper/etc/config bk citool # check in the config change

Note that the BitKeeper administrative files are also revision controlled, so this change will show up in your revision history.

For more information about repository configuration, please see

bk helptool config-etc

"I just checked in some changes, and now I'm getting weird compile errors!"

The pre-kbuild 2.5 Linux build system has some interesting quirks. One of these quirks is that if a required header file doesn't exist (because you just checked it in and it wasn't checked back out), it creates an empty file with the correct name. Naturally, this causes compile errors.

To fix this problem, remove all zero length header files in include/:

find include/ -size 0 -name '*.h' -exec rm {} \\;

Check out the files read-only:

bk -rinclude co

Most kernel developers set up their repositories to automatically recheck out checked in files read-only, by adding ``[]checkout:get'' to the end of their BitKeeper/etc/config file. See the previous question for details on how to do that.

"I'm trying to edit a file, but bk tells me that a writable copy already exists."

See the answer to the next question.

"I edited some files, but when I try to check them in, citool isn't finding them."

For some reason, the file you changed was not marked as ``edited'' but was changed to writable. To mark all writable files as edited without overwriting your changes, run:

bk -r check -f

To list all files that are writable but not edited, run:

bk -r check -w

"I made some changes, but they don't appear when I run ``bk revtool''."

Running ``bk revtool'' without arguments tells it to show you a graph of the changesets in the repository. If you haven't created a changeset, you won't see your changes in the changeset graph.

To view history of a particular file, run:

bk revtool filename

"How do I view all my un-checked in changes?"

Run:

bk sfiles -gc | bk difftool -

Or, if you prefer non-graphical tools:

bk -r diffs

"How do I create a patch?"

It depends on what you want to create a patch from. If you want to create a patch containing all the changes in one changeset, run:

bk export -tpatch -rrev > ../patchfile

If you want to create a patch containing all the changes in a range of changesets, run:

bk export -tpatch -rrev1,rev2 > ../patchfile

If you want to create a patch containing only the un-checked in changes in your tree:

bk -r diffs -u > ../patchfile

If you want to create a patch containing the un-checked in changes in your tree plus the checked in but not yet committed changes:

bk diffs -u -Clast_changeset_rev > ../patchfile

"How do I apply a patch?"

You can do this two separate ways, the first is with the normal patch command:

patch -p1 < ../patchfile

The patch command will automatically attempt to check out each affected file in read/write mode, since patch knows about SCCS, and BitKeeper is SCCS compatible. The second way is with the BitKeeper import command:

bk import -tpatch ../patchfile .

"How do I send changes to other developers?"

It depends. We'll talk only about the technical aspects of sending changes around using BitKeeper, not the politics or etiquette of sending changes.

If your changes are in a publicly accessible BitKeeper repository, tell other developers to run:

bk clone bk_url

Or if the other developer already has a clone of the same repository:

bk pull bk_url

Be aware that the other developer will get all your committed changes.

Otherwise, create a GNU patch using the directions from the ``How do I create a patch?'' question and send that.

"How do I update my tree?"

Run:

bk pull

If the parent tree (the one you cloned this tree from) has moved since you cloned it, run this first:

bk parent bk_url

"Can I undo my last set of changes?"

Yes, but it depends on what set of changes you want to undo.

To undo the last changeset:

bk undo -rrev

To undo all the changesets after a certain revision:

bk undo -arev

To undo a changeset which is in the middle of a series of changesets:

bk cset -xrev

To undo changes to an un-checked in file:

bk unedit filename

To undo the checked in but not committed changes to one file:

bk revtool filename # Find rev number bk stripdel -rrev file

To undo all changes from the last pull:

bk unpull

"I canceled a pull and now my tree is locked, how do I unlock it?"

Abort the pull with:

bk abort

"bk pull failed, what do I do now?"

If one of the last output lines was something like:

resolve: 1 unresolved conflicts, nothing is applied.

Then the auto-merge algorithm couldn't resolve a conflict and you need to resolve it by hand. Run:

bk resolve

And follow the menu prompts to finish the resolve. Choose 'f' to run the 3-way graphical merge tool.

"bk push failed, something about being 7 changesets ahead of my repository?"

You need to pull all the changesets in the parent repository and merge them before you can push your local changes to the parent.

bk pull bk push

Merges only happen on pulls, for several reasons. The most important reason is that if you push to a parent repository used by several other people and you need to hand-merge some changes, the repository will be locked for several minutes and no one else will be able to push to it during that time.

"Pushes and pulls hang when using bk over ssh."

This is a bug in OpenSSH, which is fixed in version 2.9.9. Upgrade your version of OpenSSH.

"How do I set up an ssh accessible tree for multiple read/write users?"

The easiest way is to have one user on the hosting machine that owns the files in the repository. Then put ssh public keys for all read/write developers into that user's .ssh/authorized_keys file.

"Why do the revision numbers associated with changesets sometimes change when I pull from another tree?"

When you create a new changeset, BitKeeper assigns it the next logical revision number. Since each repository operates independently from other repositories until you do a push or a pull, your local repository has no way of knowing what numbers are being assigned to changesets in other repositories. When you do a pull, BitKeeper sometimes finds two changesets with the same revision number and renumbers one of the changesets. All the information is the same, but the revision number assigned to that particular changeset is now different.

If you want to be able to refer to a particular changeset without using a version number, then tag it with this command:

bk tag -r

"I don't understand bk URLs. Something like http://bkbits.net/linux-2.5 is easy to understand, but what about the others?"

We'll use the ``bk clone'' command to show the different types of bk URLs.

If the bk daemon is running on the default HTTP port:

bk clone http://some.website.com my_repo

Or:

bk clone bk://some.website.com my_repo

If the bk daemon is running on port 5555:

bk clone http://some.website.com:5555 my_repo

Or:

bk clone bk://some.website.com:5555 my_repo

If the tree is accessible only through ssh and the login shell for the remote user is normal, e.g., /bin/bash:

bk clone username@hostname:/path/to/repository my_repo

If the tree is accessible only through ssh and the login shell for the remote user is the bk daemon:

bk clone bk://username@hostname/path/to/repository my_repo

If the tree is on the local filesystem:

bk clone /path/to/repository my_repo

"How do I move a repository?"

Repositories can be moved around on the local filesystem with a mere:

mv old_directory_name new_directory_name

If you are moving a repository to another host, just:

bk clone bk_url new_repo

And remove the old repository when you are done, if you desire.

"How do I export a plain text version of the repository?"

Run:

bk export -tplain ../plain_text

You can also specify a revision to export the tree as of:

bk export -r -tplain ../plain_text

HOWTO's

License Keys: Closed Source

For most closed source projects, the license keys are installed in a repository. They may also be stored in a system level config file. Please see bk help config-etc for more information about the system level config file.

Installation (New Repositories)

• save the email message with license keys as a text (.txt) file
• download bk and install if you haven't done so already

• bk setuptool

• when prompted for key and signatures, click "From file..." and choose the saved message.

Installation (Existing Repositories)

cd repo/BitKeeper/etc bk edit config # edit the config file: # remove license line if there is one (ditto for licsign lines) # add the license and licsign lines you were sent bk delta config bk commit

License Keys: Open Source

What needs to be done

In order to start using BitKeeper license keys in your open source projects, you need to be able to use the keys without putting them in the repository. See the explanation below for why the keys need to remain outside of repositories.

To use the license keys you can do one of two things, you can use a system level config file or set an environment variable.

System level config file
To install keys into a system level config file do the following:

vi /etc/BitKeeper/etc/config # cut and paste the license/licsign lines you were sent into the file

You will need to repeat this for all machines on which BitKeeper will be used.

Environment Variable
Instead of having license keys in a system level config, you may also choose to use the BK_CONFIG environment variable. The syntax for setting that variable and running a (sh) command is as follows:

BK_CONFIG='option:value;option2:value2;' bk cmd

or

# bash export BK_CONFIG='option:value;option2:value2;' # csh setenv BK_CONFIG='option:value;option2:value2;'

In commercial installation, license keys normally get installed in the BitKeeper/etc/config file of the repository. BitKeeper's license keys do not put hard restrictions on the number of users on a key. In commercial installations, this is okay because there are protections made in house that restrict usage to in-house developers and repositories are rarely made public. In the free-use world, repositories are almost always public so there must be restrictions in how license keys are installed for use on open repositories.

For customers moving status from free to commercial there are special considerations that need to be made in order to continue to publish source and also protect license keys. There are two methods that can be employed, using a system level config file or using a BK_CONFIG environment variable.

Hosted Projects
You can still continue to use bkbits.net and openlogging for your projects.

No license keys are needed for the open source bitkeeper client. Consumers of your open source projects can use the client to do "clones" and "pulls" from bkbits.net.

Multiple code lines

Suppose that you have "dev" and "bugs" as your two lines of development. Further suppose that fixes added to "bugs" line should go into "dev" but not the other way around (this matches a large percentage of all software development efforts).

Create two copies of the same repository and name them "bugs" and "dev". We put them in /home/bk/bugs and /home/bk/dev.

When you need to do a bugfix, clone the bugs tree; when you want to do development, clone the dev tree.

A project lead will periodically pull changes from the main bugs tree into the dev tree to keep it up to date.

PROS:

• simple to explain
• all work tends to converge on the trunk
• works for most people
• follows the "work forward model"

CONS:

• you have to be careful not to push the dev tree into bugs, use bk level to prevent this from happening.
• can only easily work "forward", i.e., work may flow from bugs to dev but not backwards. It's possible to move stuff backwards as patches but it isn't as easy as the other way.

CVS to BitKeeper This section is for people familiar with CVS and is sort of a translation of commonly used CVS commands and actions into BitKeeper commands.

In CVS, the central/master repository is set as follows:

setenv CVSROOT username@hostname:/path/name

In BitKeeper, you would use:

bk parent username@hostname:/path/name

See bk help parent for all uses of the command.

In CVS, run all remote traffic is run over ssh with the following:

setenv CVS_RSH /usr/bin/ssh

BitKeeper defaults to using ssh, but it's possible to do the following:

setenv BK_RSH /usr/bin/rsh	# csh
export BK_RSH=/usr/bin/rsh	# sh

In CVS, checking out a first-time clone for making changes is done as follows:

cvs co [files or dirs]

In BitKeeper, the equivalent is:

bk clone username@hostname:/path/name [destination]

Note that BitKeeper currently allows you to get only the whole tree.

In CVS, to add changes there is no file locking, you simply edit your file copies and then commit. The ``locking'' and conflict checking is done on write back. To lock a file for editing in BitKeeper:

setenv EDITOR /usr/bin/vi
alias vi 'bk editor'
vi foo.c	# checks out and locks foo.c and then execs $EDITOR; works with multiple file args

Alternatively:

bk edit	# locks everything
vi foo.c bar.c whatever.c

Changes are committed to a central repository in CVS in one of the following ways:

cvs commit [file...]
cvs commit
cd some/dir; cvs commit	# will only commit all changes from some/dir

The equivalent in BitKeeper is:

In CVS, to update your clone tree with the central repository's contents:

cvs update [-d]

# -d will pull in directories as well

In BitKeeper, the equivalent update is:

bk pull

Search

You may enter multiple terms in the search window. Each page which contains any of the terms will be a match (unless you check the "All words..." button below). The list of words found in a page is listed after the page name in the results.