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/Nested repository collections
	BK/Nested is technology that allows you to scale all of the benefits of distributed version control to very large source bases, such as an entire operating system even if it has gigabytes or terabytes of binaries, millions of files, in thousands of packages. A nested collection is made up of a product repository at the top that binds together multiple component repositories. We tested out the technology on the FreeBSD source tree which consists of the kernel, compilers, debuggers, editors, and all the other packages. BK/Nested lets you work on as much or as little of the collection as you need; BitKeeper does all the bookkeeping to make sure that everything is where it should be in time and space. The benefits of BK/Nested include scaling up with full audit trail and consistency, scaling down to as little as one component for performance, outsourcing one or more components without leaking any of the surrounding intellectual property, and reusing components in different products, all while retaining the workflow benefits provided by the basic BitKeeper system.
BK/BAM (Binary Asset Management)
	BK/BAM is technology that helps when your development includes large binaries. BK/BAM has one or more BAM servers that have all versions of all binaries. Developers have quick local access to those files that are most relevant to their current work, and older binaries are archived in the BAM server[s]. BK/BAM is somewhat of a hybrid, with most of the data in a centralized server. Centralized servers can be a performance problem; anyone who has used a system like CVS, SVN, Perforce, etc., from a remote site is painfully aware of the issue. BK/BAM does not have this problem, you can have as many servers as you like; the remote site problem goes away.
BK/Web
	BK/Web is a web interface for browsing and searching BitKeeper repositories that augments the suite of BitKeeper GUI tools. BK/Web is typically used by people who wish to follow the progress of a project in a browser. BK/Web is also used to link bug reports to the changes that fixed the problem. Users can search or browse work history based on a variety of parameters including changesets, users, tags, or the files themselves.

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 Windows platforms).

The list of supported platforms is currently:

• AIX 4.1.5 and later on PPC
• FreeBSD 4.x, 5.x, 6.x and 7.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/IA64 (Intel 64bit Itanium)
• Linux/MIPS (Sibyte)
• Linux/PARISC (HP RISC platforms)
• Linux/PPC
• Linux/S390 (upon request)
• Linux/SPARC
• Linux/x86 (x86, AMD, Cyrix, etc)
• Linux/x86-64 (AMD or Intel with 64bit extensions)
• MacOS X on PPC and x86
• NetBSD on x86
• OpenBSD on x86
• SCO OpenServer Release 5 on x86
• Solaris 5.6 and later on SPARC
• Solaris 5.7 and later on x86
• Windows 2000 (to be phased out by 2011)
• Windows 2003 server (to be phased out by 2011)
• Windows XP
• Windows 2008 server
• Windows Vista
• Windows 7

Please contact us for more information if your platform is not currently supported.

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. An inexpensive PC can 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. An expensive 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 who 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 has hosted 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 test drive will walk you through the installation and use of BitKeeper in the day-to-day life of an average Windows developer. This test drive does not cover the more advanced topics of distributed source control but is instead meant as an introduction to life in BitKeeper on Windows.

This test drive covers the following topics:

• Installing BitKeeper
• Setting Up a Work Environment
• Pulling Changes from a Parent
• Making Changes
• Viewing Changes
• Committing Changes
• Viewing Revision History
• Pulling and Resolving a Conflict
• Committing a Merge
• Pushing Changes to a Parent

The test drive makes it easy for you to follow along with what you should be doing by providing instructions in separate command boxes. These boxes will show you exactly what to do at each step of the test drive. The prompts you follow will be different depending on how you're running the test drive. They will look like this:

BitKeeper GUI prompt: When you see this, follow the instructions in the BitKeeper GUI

Windows GUI prompt: When you see this, follow the instructions in Windows Explorer.

Command Prompt: When you see this, follow the instructions at the open Command Prompt.

Note that any time you see a Windows command prompt throughout this test drive, the contents of that window may not look like what you see in your window. The output from BitKeeper changes from version to version, so what you see may not be exactly what is pictured in the test drive. As long as things don't look like an error, you should be ok.

If you're ready to get started, let's move on.

First Step: Installing BitKeeper on your system

Installation

So you're ready to try out BitKeeper? First things first, let's get it installed on your machine! If you have not downloaded BitKeeper already, you should request an evaluation key and download information now.

Once you've downloaded the software, continue through the installation steps.

Double click the installer to launch it, and a window will first pop up telling that it is unpacking. As soon as that's done, the installer should pop up and get us rolling.

Click through the welcome screen, and the first thing you're presented with is the license screen. This is where you'll enter your demo license. Don't worry though. You don't have to type the whole thing. You can copy-and-paste it into the fields, or you can load it from a file. Once you've entered your license key, the next screen asks you to accept the BitKeeper End User License before proceeding with the installation. Just click the Accept button once you've read the agreement and click Next to move on.

The next thing we're presented with is where to install BitKeeper. You can choose any location you want, but if you're not sure, it's best to just let it install to the standard Program Files directory.

Next we see a screen offering a few optional install pieces that we want. The two options on this screen are checked by default, and we want to leave them that way. If you don't run Visual Studio and don't plan to, you can uncheck the Enable Visual Studio integration button, but we definitely want to keep the Windows Explorer integration enabled. This enables the BK plugin for Windows Explorer, and it's what the entire rest of this test drive is based on.

Once you've selected your options, just click Next to move forward and start the installation.

Once the installation is complete, we should be ready to roll!

Next Step: Get a demo repo cloned to your machine

Setting Up the Demo Repo

Now that we have BitKeeper installed on your system, we're ready to try it out.

This section of the test drive will cover:

• Cloning a remote repo to your machine
• Cloning a local repo to make a working copy

Next Step: Cloning a remote repo to your machine

Cloning a Remote Repo

Now that you've completed the installation step of the test drive, we're ready to setup a repository for our demo.

First, we'll start by creating a simple directory to work in. For the purposes of our test drive, we're going to simply use C:\BK as our directory. This is the directory we will use to hold the repositories we clone and work in while we're working in BitKeeper. You can create whatever directory you like for your test drive.

Navigate to C: Right-click on the white background of the Explorer window. Click New -> Folder. Rename the newly-created folder BK.

Now that we have our directory setup, the first thing we'll do is clone a repository. Let's open Windows Explorer and navigate to our directory. Again, you can see in the screenshots that we're using C:\BK as our directory. Yours may be different.

Right-click on the white background of your Explorer window. Click BitKeeper -> Clone a Repository...

A small dialog will popup asking for some information about what you want to clone and where you want to put it. For the purposes of this test drive, we're just going to clone the demo repository.

Check the Get the demo repository box. Click the Clone button.

After clicking the Clone button, you will see a command prompt window pop up and some data start flying by. Don't worry. That's normal. While the Windows Explorer plugin makes it easy to navigate BitKeeper in the Windows world, it is still a command line tool for many of its functions. You will see a command window popup like this from time to time, but it's usually only there to show you what is going on as BitKeeper performs the requested action.

Once the clone is complete, the command window will be left open to show you what happened and/or to let you perform further command line actions. Your window should look something like this, but it may not be exact depending on your version of BitKeeper.

Close the command prompt window.

Now your directory should look something like this:

If the clone doesn't work for some reason, you might need to tell BitKeeper about your HTTP proxy if you are behind one. You can do this with:

Open a command prompt. set http_proxy=http://your_proxy.your_company.com:80/

For more information about methods of accessing repositories, see the url manual page in the helptool. You can launch helptool like this:

Right-click anywhere in Explorer. Click BitKeeper -> Help... Click More Help...

Next Step: Make a copy of this repo by cloning it

Cloning a Local Copy

You've just cloned a remote repo to your local system, and we're ready to work! Notice that BitKeeper has placed an overlay icon on the folder to show that this is a BitKeeper repository. When working within the Explorer plugin, BitKeeper uses several icon overlays to give you an idea of what you're looking at with a glance.

Now, this demo repo was cloned from bkbits.net, and we don't have permission write back to the parent repository, so the next thing we want to do is make another clone of our new repo to the same directory so that we can make some changes.

Right-click on the white background of your Explorer window. Click BitKeeper -> Clone this Repository...

You'll see the familiar clone dialog pop up. Notice that the dialog has already filled in the name of the repo we are cloning and a suggestion for the copy of the repo. We'll just keep the defaults for now and make a new bk_demo_copy directory to play in. You will see the command window fly by again as the repo is copied. Once it's done you can close the command window, and your directory should look like this:

You should now have a directory with two repos: bk_demo and bk_demo_copy. Each repo knows about where it came from and who its parent is. bk_demo_copy knows that bk_demo is its parent, and that's where it will pull its updates from and send its changes to. bk_demo knows that http://bkdemo.bkbits.net/bk_demo is its parent, and that is where it will pull updates from.

Next Step: Pulling changes from a parent

Pull Changes from a Parent

So we just finished setting up the demo repo, and now we're ready to start working in our new copy!

First things first. Let's try and pull changes from our parent to make sure we have the latest code. A clone will automatically pull the latest revision of the code, and we haven't made any changes to our parent, but we're going to do it anyway just to see what it looks like.

Right-click on the bk_demo_copy folder. Click BitKeeper -> Pull Changesets from Parent.

A dialog will popup asking where we want to pull from. It will populate with the value of our parent repo by default, and that's where we want to pull from, so we'll just leave that in there.

Click the OK button.

Another command window will pop open and try to pull any new changes from our parent. In this case it won't find anything because we haven't made any changes in the parent. Close the command window, and let's try and pull changes from another parent that does have some changes in it.

Right-click on the bk_demo_copy folder. Click BitKeeper -> Pull Changesets from Parent. For Target URL use: http://bkdemo.bkbits.net/bk_demo1 Click the OK button.

You should see another command window pop up as BitKeeper pulls any changes from that repository. This time we should see some changes come through. Specifically, we see that a change has been made to e2fsck/region.c. You will see some other stuff in the command window that gives you a little more information about what just happened. The window should look like this, but it may not match exactly what you see:

If we look at this a little closer, BitKeeper is telling us what just happened. We see that BK is pulling two files: ChangeSet and e2fsck/region.c. The ChangeSet file is a file you will see with every change. It is the main file that tracks change sets within BK, and it is updated each time a change is committed. The second file is our actual code change. We see BK run the resolver and apply our changes to the changed files and then run a consistency check to make sure that data integrity is correct.

Next Step: Make some changes of our own

Making Changes

Now that we've pulled in some changes, we're ready to talk about making changes of our own.

This section of the test drive will cover:

• Checking out files
• Modifying and creating files
• Viewing Changes in difftool
• Checking in your changes

Extra Credit:

• A word on checkout modes in BitKeeper
• A few comments about comments

Next Step: Checking out files

Checking out files

Well, now that we've pulled in some changes, we're ready to make some changes of our own! Let's dig into that bk_demo_copy repo and see what all we have.

Double-click the bk_demo_copy folder.

Hmm. Some files with big green buttons on them and a subdirectory. Ok, so the files with the big green buttons on them are files that are under BitKeeper control. The green icon with a minus sign is showing us that these files are checked out in read-only mode. Let's go look in that e2fsck subdirectory and see what's in there.

Double-click the e2fsck folder.

You can see that the files in this directory are also marked with the green minus icon, telling us they are marked read-only, so the first thing we want to do is mark the files for editing so that we can start making some changes.

Right-click on the white background of your Explorer window. Click BK Edit Files...

If no files are selected, this action means to checkout all of the files in the current directory for editing. Now our directory should look like this:

Ok! The green check marks say that these files can be edited, so we're ready to make some code changes! If you want to learn more about why we need to checkout files for editing, see the note on checkout modes for extra credit.

Next Step: Modifying and creating files in a repo

Modifying and creating files

Now we're ready to make some changes. Let's open up recovery.c in your favorite editor and change all instances of jread to Jread.

Open recovery.c in your favorite text editor. Find and replace all instances of jread with Jread. Save recovery.c and exit the editor.

As soon as we save the file, the icon in the Explorer changes to a red minus icon.

This is the BK plugin telling us that this file has been modified and needs to be checked in. Which we'll get to in a minute. First let's make another change. This time, let's create a completely new file in our directory. Let's create a new file called foo.c and just put a little something in there. It doesn't matter what.

Create a new text file called foo.c.

Now we see that BK has marked our new file with a blue question mark, like this:

This is the BK plugin telling us that it doesn't know anything about this file. We don't need to tell BitKeeper about any new files we create unless and until we're ready to add them to our repository. You can happily work along in new files and add them to your repository when you're ready along with any other changes.

Next Step: Viewing our changes

Viewing Changes

So now that we've made a few changes to our repo, let's take a look at those changes and see what all we've done.

Right-click on the white background of your Explorer window. Click BK Diff Directory...

This will bring up the BK difftool that shows us side-by-side differences in BitKeeper-controlled files. It will load showing the first changed file and centered on the first change in that file. Like this:

So, where did foo.c go?! Well, BitKeeper doesn't know anything about foo.c so there's nothing to diff. Don't worry though. When it comes time to commit, BitKeeper will tell us there is an extra file there it doesn't know about and give us the option to include it then.

Next Step: Committing our changes

Committing Changes

We've made some changes to our repo, and we've looked at those changes in the difftool, now we're ready to commit our changes!

Right-click on the white background of your Explorer window. Click BK Checkin Tool...

This will launch the BitKeeper checkin tool that we will use to walk through, comment our file changes and then commit our changeset to the repository.

So, we can see in our file list that citool has found the changes we made to recovery.c as well as the extra foo.c file we created. Citool has already selected the first modified file under BK control (which is recovery.c) and is showing us the changes made to the file in the lower window. Citool doesn't need to show us the entire contents of the file or its changes, it's showing us just the differences between our current, working version and the last version committed in the repo.

We can see all of our changes to recovery.c right there, and the diffs look good, so let's give it a comment. For a little extra reading, you can read about our thoughts on commit comments. You can enter any comment you want for the changes, and notice that the icon on the file shifts to a green check to show us that this file is now set to be included in our commit.

Give recovery.c a comment. Select foo.c in the file list.

When we click on foo.c, citool sees that this is a new file and doesn't know anything about it, so it just dumps the file contents to the lower window.

Click the icon next to foo.c.

We see that citool has now marked this file to be included in our commit and has entered a default little comment about the file being new. You can change the comment if you like, or you can just leave the default new message in there.

We have two files ready to be committed, now all we need is a ChangeSet comment.

Click on the ChangeSet file

You should see the files we're ready to commit down in the lower window along with their per-file comments. This gives you an idea of what is about to be committed with this changeset. Remember, this comment is more a summary of the overall change, so just a few lines describing what the change is about should do. You can comment it with anything you like for a test drive here. Once you give the changeset a comment, you should see the green check next to the ChangeSet file, and you should now see the Commit button over on the right is ready to go. It should look something like this:

Click the Commit button twice

Now all the magic starts happening. The citool will walk through and check in each of the files and then commit the whole thing as a changeset to our repository. Once the commit has completed with no problems, the citool will automatically close. Now we can see in the Explorer that all of our files are green again. Notice that foo.c and recovery.c are now marked as read-only again. This is, again, because our repo is in checkout: get mode. When a commit is done, each file in the cset is checked in and committed and then checked back out in whatever the default mode is.

So, we've pulled in a change from a different parent, and now we've gone and done a little work and made our own change.

Next Step: Take a look at the history of our changes

Using Revtool

We've just committed some changes to our repo, so now let's take a look at the revision history of our repo through revtool. This section will cover:

• Launching revtool in a repo
• Looking at a changeset through revtool
• Looking a specific file in a changset in revtool

Next Step: Launching revtool in a repo

Launching Revtool

Right-click on the white background of your Explorer window. Click BitKeeper -> Revision Tool...

The revtool will pop up with the revision history of our repository. When revtool is called on a repo without a specific file, it will show the history of the entire repo, which is all of the changesets that have been committed. We're not looking at per-file commits here, we're looking at things from the perspective of the csets. This is where your changeset comments come in handy for browsing back through the history. Let's take a look at the revtool and what all of that stuff means.

The revtool is arranged with a revision graph on the top and then a description window on the bottom. When revtool is run on a repository, the default configuration is to show the last 50 csets along with their descriptions down in the bottom window. You should see the previous commits in the repo as well as the new commit that we just made to the far right on the graph. You can see down in the bottom window that our last commit is on top of the history.

Next Step: Take a look at a changeset in revtool

Looking at a Changeset

Click the last commit in the revision graph.

When we select a revision in the graph, we see all of the comments for that cset in the lower window. We can see the overall changeset comment we entered as well as the per-file comments for each file in the cset. Here we can see the new foo.c file we added and its comment as well as the recovery.c file we changed and what our comment on that was. The comments tell us what was changed at a glance, but what if we want to see what was actually changed in the code?

Next Step: Look at one file's changes in our cset

Looking at a file

Click the line below e2fsck/recovery.c in the text window.

You should see another revtool fire up with just that file and its history. Now we are looking at revtool from the perspective of a single file, not the repo as a whole.

It should look something like this:

When revtool is launched on a single file within a repo, the default is to show an annotated view of that file at its latest version. This shows us the full contents of the file with each line annotated by the revision it was first introduced as well as who made the change. We can see from our recovery.c file that we are currently at revision 1.7, which was our recent commit. This view shows us the entire file, but we really just wanted to see what was changed between our recent version and the previous version. For that we just hit d to bring up the diff view.

Type d

You can also click nodes in the graph to see diffs of a file. Select the first revision in the graph by clicking the left mouse button and then select any other revision by clicking the right mouse button. Revtool will show you the differences between those two versions. Typing d will automatically select the previous revision and diff the two, but the two revisions don't have to be adjacent. You can select any two revisions with your mouse and see the differences between them.

Revtool will automatically select the previous version and then diff that with the currently-selected version. It should look like this:

Ahh, there we are! Now we can see the diffs of what was changed in our last commit. Yup. Just as I thought. We changed jread to Jread.

Next Step: Pull some other changes that need a merge

Merging Changes

We've just finished up a quick overview of changeset history by using revtool, and we saw how easy it was to pull in changes from another repo that merged without a problem. But now let's see what it's like to pull in changes that don't merge so nicely. This section will cover:

• Pulling and Resolving a Conflict
• Merging a file
• Committing a merge

Next Step: Pulling and Resolving a Conflict

Pulling and Resolving a Conflict

So, here we are. We've changed some code in our repo and made a small commit with our changes. We can see from the history what our changes look like, and now we're ready to move on and keep working. But now we find out that we need to pull some code from another repo. Someone else has done some work, and we need to merge their changes into our work before we keep going.

Most often when changes are pulled into your repo, BitKeeper will handle auto-merging the changes without a hassle. But sometimes you pull changes from another repo that touch the same files in the same areas as ones you have already changed. This creates a conflict that BitKeeper doesn't know how to solve, so it relies on you to merge the conflict by hand. Let's pull in a change that will cause a conflict and see how that is resolved.

Right-click on the white background of your Explorer window. Click BitKeeper -> Pull Changesets from Parent...

You'll see the familiar little pull dialog, but this time we're going to pull from http://bkdemo.bkbits.net/bk_demo2. Put http://bkdemo.bkbits.net/bk_demo2 into the Target URL box and click OK. The command window fires up again to do the pull, only now we see something like this:

BK has run into a conflict while merging the new changes, and it doesn't know how to resolve it, so it has dropped us into the resolver. It's waiting on us to decide what to do. If we press Enter at this prompt, we're given a list of available commands.

Next Step: Merge it all together

Merging a file

We've pulled in a cset with a conflict, and now we need to merge the changes. In our case, we want to step into the 3-way merge tool and do our merge graphically from there.

Type f and hit Enter.

BK will fire up the fm3tool for us to do the merge. Let's take a look at this thing:

Whew! That's a lot of stuff for one window! Let's start at the top and work down. The top row shows the two changeset comments side by side so that you can see what you are working with. The row below that has two text windows showing a side-by-side diff of the changes. We can see that the fm3tool has already moved us to the first conflicting change in our merge, and the conflicting pieces are highlighted in orange.

Down in the lower window you can see the result of our merge, and it currently has a big chunk marked UNMERGED. This is showing us the first conflict and where in the file it needs to be merged. We'll merge our changes by selecting the pieces we want from each cset. This is also where we can jump into the file and edit the changes by hand if we want, but we won't be doing that today.

So, someone has changed the same jread lines that we changed in our commit. We need to look at the two changes and figure out which one is the one we want. Our changes are on the left, and the changes we're pulling in and trying to merge are on the right. It looks like our changes are the ones we want, so we want to execute the merge such that our changes are taken over the new changes we're pulling in.

Let's pick a change on the right first to see what happens.

Click the right window on the line with jREAD highlighted in orange.

You'll see that line appear in the lower window where the UNMERGED block used to be. We've now resolved the first conflict, but we didn't actually want that line, we wanted the other line.

Type u.

This will undo our previous change and move the conflict back to an UNMERGED state.

Click in the left window and click the line with Jread highlighted in orange.

That puts our change down in the lower window in place of the UNMERGED block.

That looks good. We can also see in the lower right window that our first conflict has now been resolved. Only two more to go!

Click the right arrow button or type ].

The fm3tool will jump to the next unresolved conflict in the file. Again it looks like we want our changes, not the incoming ones.

Click the left window and click the line with Jread highlighted in orange. Click the right arrow button or type ] to move to the last conflict. Click the left window and click the line with Jread highlighted in orange.

That should be our last conflict. We're done!

Click File -> Save or type s to save our changes and exit.

Next Step: Commit our merged changes

Committing a Merge

We've just pulled and merged a conflict from another parent repo, and now we're ready to commit our merge. BitKeeper has dropped us out of the fm3tool and back into the resolver which looks something like this:

Type C and hit Enter.

This will commit our merged changes. The citool that we've now seen before will pop up to show us our merged changes. We can see the changes we made to recovery.c, and it looks like the ChangeSet already has a comment. Let's make a comment for recovery.c. You can use the comments to explain what you did with the merge, or you can just use something like "Merged."

Select the ChangeSet file.

BitKeeper has already filed in a simple comment stating what happened. We pulled bk_demo2 into our bk_demo_copy and merged the two. You can take the time to write in your own merge comments here, but the standard merge comments are useful for noting the difference between a merge and a regular commit when looking through the change history.

Click the Commit button twice.

The resolver finishes up the pull, does an integrity check, and then it's done. You can close the command window once you've read what happened.

Last Step: Push our changes back to our parent

Pushing Changes Back to the Parent

We committed a merge to our repo, and now we're finally ready to push our changes back upstream to our parent repo. But before we do that, let's make sure our parent doesn't have any changes we need to pull first. BitKeeper will not let you push your changes to a repo that has any changesets you don't already have, so we need to check for any changes before we push. Note that BitKeeper will stop you from doing the push if there are changesets you need to pull, so you don't absolutely have to check for them, but it's good practice here.

Right-click on the white background of your Explorer window. Click BitKeeper -> View Remote Changesets...

A command window will pop up to list any remote changes in the parent that we don't already have in our repo. Of course, we already know that our parent doesn't have any changes, so we didn't need this step, but now we can see, for sure, that there are no changes in the parent:

BitKeeper shows us the changes command being executed and the parent repo we're checking against followed by the list of changesets on the remote side if there are any. We can see here that there are no changes in the parent that we need to pull. Close the command window, and let's check and see what changes we're about to push to our parent.

Right-click on the white background of your Explorer window. Click BitKeeper -> View Local Changesets...

Another command window will open up listing the changesets we have that our parent does not have yet. It should look something like this, but it may not be exact depending on your version of BitKeeper:

Ok. We have several changesets that we've made that need to be pushed back to our parent. Let's take a look at them. The first two changes were pulled in when we pulled from . The third changeset is the one change we made locally where we modified recovery.c and added the new foo.c file. The final change is the merge we did. Notice that BitKeeper has marked this changeset as a MERGE changeset.

Those changes look good. We're ready to push them back to our parent.

Right-click on the white background of your Explorer window. Click BitKeeper -> Push ChangeSets to Parent.

The familiar dialog pops up asking us where we want to push our changes, and our original clone parent is the default.

Click OK.

The command window pops up and starts doing its thing. We see from the output that BK has pushed our changed files back to our parent, and then it ran a consistency check on the remote repo to make sure everything is ok. Everything looks good.

Well, it looks like that's it for our Windows Test Drive!

Now that you have an idea of how BitKeeper works and how to interact with BitKeeper on Windows, you should poke around at some of the rest of the options in the Explorer plugin and see what all you can do. Open up the helptool and read through some of the docs if you want to learn more about some of the commands you do.

Right-click anywhere in Explorer. Click BitKeeper -> Help... Click More Help...

If you run into any problems, drop us a line at support@bitmover.com and let us know. We're happy to help!

Extra Credit Work

This section is not part of the basic testdrive but is meant to expand on a few of the topics mentioned throughout it.

• A word on checkout modes in BitKeeper
• A few comments about comments

Checkout Modes

A quick word about checkout modes.

By default, BitKeeper operates in a "clean" checkout mode. This means that all files must be explicitly checked out in either read-only or read-write mode. You can specify that a particular repository should be in "checkout: get" or "checkout: edit" mode as well as specify in your own configuration what the default mode should be.

Available Checkout Modes

checkout: get
In get mode, BK will automatically checkout each file in read-only mode (using bk co ) after doing a checkin.

checkout: edit
In edit mode, BK will automatically checkout each file in read-write mode (using bk edit ) after doing a checkin.

checkout: last
In last mode, BK will preserve the state of the file before checkin.

checkout: none
In none mode, BK will clear the file after doing a checkin. This is the default.

The repositories we are using for this test drive have been marked "checkout: get" which means that all files within the repo will be checked out in read-only mode by default. That's why we have to first checkout the files for editing before we can make any changes to them. In most cases you will usually just checkout the files you plan to modify for editing and leave the rest as read-only as it makes it really easy to see what you're changing from the Explorer. If you were to run in "checkout: edit" mode, all of the files would already be in the directory and writable after a clone, and you could skip the step of having to check them out.

File and ChangeSet Comments

A quick word on comments. Unlike some source control management systems, BitKeeper requires per-file and per-cset comments. That is that each file in a changeset needs a comment as well as an overall comment for the changeset itself. Generally speaking, your per-file comments are meant to describe the actual change to that file and maybe some detail about what was changed. The changeset comment is more a summary of the overall change being committed. You will see more of why this is a good thing when we start looking back at the revision history through the revtool.

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

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

BitKeeper 5.x release dates

Date	Release name
2011/08/12	bk-5.3
2011/03/21	bk-5.2
2011/02/16	bk-5.1.1
2010/12/10	bk-5.1
2010/10/11	bk-5.0

BitKeeper 4.x release dates

Date	Release name
2010/04/02	bk-4.6
2010/02/12	bk-4.5
2009/09/14	bk-4.4
2009/03/30	bk-4.3.1
2009/02/02	bk-4.3
2009/01/14	bk-4.2.1
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

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 have not, and will not, gift, rent, sell or resell your private information to other companies or individuals for any purpose. That has been our policy since 1997 and it has never changed.

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.

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.