|
| |
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
|
|
| |
|
|
|
|
What They're Saying
|
|
"BitKeeper is one of the most advanced SCM products on the market." -- HP
"BitKeeper allows our development teams to be more agile and flexible in meeting our customers' needs." -- Maxtor
|
|
|
Developers
Are broken builds affecting your productivity?
BitKeeper workspaces are independent replicas where you can
check in code, do more work, and continue checking in without
polluting the main tree with incomplete work. Check-in, merge,
and test -- all in your sandbox -- and push
changes up to the main tree when you decide it's ready.
Working remotely? Offline?
Legacy client-server based SCM's may be making your check-ins
slow and cumbersome, especially if you have multi-site or
remote developers. With BitKeeper, common operations such as check-ins are
done locally so they are fast. At the same time, synchronizing
repositories over the network is also efficient because only
the incremental changes in metadata are transferred.
Want to share, review, and test code easily with other team members?
No problem. BitKeeper enables sideways, peer-to-peer updates
that promote collaboration early in the development process.
Work, merge, and test collaboratively with team members
without ever having to leave a version control environment.
No one else is affected until the group is ready to push
its changes up to the main tree.
Is debugging and understanding code becoming increasingly difficult?
BitKeeper keeps the most accurate and detailed audit history of any
SCM solution in the market with tools to easily query that history. For any modification, developers can
quickly see what related changes were committed in the same changeset.
BitKeeper's fully annotated history
browser also shows all previous versions of each line of code,
helping developers quickly see how the code evolved.
|
Do you have other problems that are impeding your productivity? Try BitKeeper for yourself with a
free, no obligation evaluation
or contact us at sales@bitmover.com to see if BitKeeper will address your needs.
|
Architects
Need a better handle on reviewing and quality-controlling your group's work?
BitKeeper makes it easy to create staging repositories where members of a group
can check-in, merge, test and work collaboratively without affecting any other
group or the main tree. The lead or the architect can then review and push updates
to other groups once the changes are ready for prime time.
Getting serious merge headaches right before a release?
BitKeeper encourages developers to merge and test as they go versus
checking in most of the work when a deadline approaches. On top of
that, BitKeeper's automerge technology is the best in the industry,
making it easy to synchronize different branches. Not only does
BitKeeper automerge more code than any other tool, it makes sure that
merges are done accurately -- without any guesswork. Merges will
also never have to be repeated across multiple branches.
Need more detailed and accurate audit trail of who did what, when and why?
Unlike most other solutions, BitKeeper does not lose individual work that went into
a merge and maintains accurate authorship down to every line of code. Issues can
be quickly isolated to the right changeset, file, line of code, and author. BitKeeper
also provides tools to query the history and generate reports or release notes.
Are rollbacks resulting in big productivity loss?
No one's perfect. Sooner or later you may find yourself needing
to roll back to a previous state. In BitKeeper, every changeset
is a potential rollback point so you will never be burned by
forgetting to tag a version. Plus, BitKeeper keeps a full audit
trail of every developer's incremental work, ensuring that
any and all good work can be replayed in the event of a rollback.
|
Do you have other problems that are impeding your productivity?
Try BitKeeper for yourself with a
free, no obligation evaluation
or contact us at sales@bitmover.com to see if BitKeeper will address your needs.
|
Managers
Are hidden costs associated with your SCM adding up?
BitKeeper's total cost of ownership is one of the lowest in the SCM
market. Though other solutions may have lower starting license fees,
hidden costs including wasted developer time, administrative overhead,
hardware costs, and upgrade costs can quickly erode their benefits.
BitKeeper not only makes developers more productive, it requires minimal
administration and dedicated hardware. BitKeeper's support level is also
unparalleled, ensuring that you get the most out of your investment.
Worried about poorly tested code seeping into a shipped release?
We've all been there. You have a critical customer demo that
bombs because someone checked in a change at the last minute that seemed harmless.
BitKeeper not only encourages changes to be peer-reviewed as
they are shared peer to peer, you can easily implement policies
where any check-in is applied to a replicated staging repository
where acceptance tests are run before the changes are pushed
to the main tree.
Need better metrics on who's doing what, when, and why?
BitKeeper's history is more detailed and accurate than any other
solution in the marketplace. Unlike other tools, you don't lose
incremental work and authorship information on merges. BitKeeper
also makes it easy to issue a full range of queries on the
work history, allowing you to track developer productivity,
project progress, and bug fixes.
|
Do you have other problems that are impeding your productivity?
Try BitKeeper for yourself with a
free, no obligation evaluation
or contact us at sales@bitmover.com to see if BitKeeper will address your needs.
|
Products
|
BK Development Platform
|
|
|
|
| |
The BitKeeper Development Platform provides powerful configuration
management capabilities and workflow control. BitKeeper was
designed to solve many of the scaling, performance, and merge
problems that legacy SCM sytems repeatedly introduce.
With BitKeeper, developers become more productive, teams can
work collaboratively without ever leaving a version control environment,
and work is more likely to be peer reviewed.
Learn more
about how and why BitKeeper will accelerate your development
productivity. If you just want to try out BitKeeper for yourself,
go to the
download and evaluation request form.
|
|
|
BK BAM (Binary Asset Management)
|
|
|   |
BK/BAM streamlines the workflow and storage associated with the
development of large binary files. Developers have quick local
access to those files that are most relevant to their current work,
and older binaries are archived in an efficient, organized structure
in a centralized location of your choosing.
Developers can maintain
sparse local trees yet still have access to the full revision history of
the files and can gain access or rollback to any prior version, whether
tagged or not.
Developers also have the luxury of working in local sandboxes with their
binary data to prevent disruption of other peoples' work or the main stable
tree.
|
|
|
|
BK Web
|
|
|   |
BK/Web is a powerful web interface for browsing and searching
BitKeeper repositories that augments the suite of BitKeeper
GUI tools. BK/Web provides a detailed graphical interface which
outlines project history.
Users can search or browse work history based on a variety of parameters
including changesets, users, tags, or the files themselves. Typical views include:
-
History summaries
-
Changesets by user
-
Tagged releases
BK/Web also includes the ability to search on changeset comments, file
delta comments, and file content.
|
|
How BK Works
BitKeeper is the configuration management platform for the BitKeeper
family of products. BitKeeper arms developers with a distributed,
peer-to-peer version control system that naturally enables
collaboration, iterative development, and peer reviews.
Developers can work faster and more productively because versioning is local,
sharing work is simplified, and all individual work is preserved.
Architects and project managers can more easily co-ordinate different
components and versions of their projects with BitKeeper's detailed
audit trail and advanced on-demand branching and auto-merging
capabilities.
How does it work?
BitKeeper groups modifications into logical units of work called
changesets, which can represent features updates, patches, etc.
Changesets dramatically improve debugging and maintaining code
by showing all of the related changes that are associated with
any one modification. Comments are associated with each individual
modification as well as the changeset that encapsulates them,
making it easy to see not only the who and what, but why.
Easy to manage repositories
At a simplified level, a BitKeeper repository is a collection
of files and the group of changesets that captures the evolution of
those files.
BitKeeper changesets are committed atomically, never leaving a
repository in an inconsistent state. Unlike other SCM solutions,
BitKeeper changesets are also immutable and fully reproducible:
you can roll back to any changeset and reapply a changeset with
the same effect every time.
Since BitKeeper tracks and groups
all modifications, including symlinks and file renames, you can
always reproduce working builds. Every changeset is automatically
tagged in effect, so reproducibility is preserved even if
someone forgets to "tag" a version.
No more breaking builds
Legacy SCM systems are client-server based, causing central repositories
to become bottlenecks, or worse, single points of failure. In BitKeeper,
each developer has a replica of the repository, giving him a revision
control environment that is local and sandboxed.
Changesets are committed to the developer's local repository -- slow
networks, offline servers, or even offline development no longer
hamper check-ins.
Organizations with remote offices, developers
working from home, or offshore development will quickly realize
the benefits of BitKeeper's fast, localized versioning. At the
same time, every organization, whether distributed or not, can
decrease the risk of check-in's that pollute global repositories
or that break the build for the entire organization.
Fast, lightweight synchronization
Synchronizations between repositories are fast because only
the delta in changesets (i.e. difference in metadata) is transferred over
the network. Other legacy SCM systems
need to traverse the entire directory tree to see what has changed.
Suppose Dave is happy with his new work and is ready to push his changesets
to the main repository. Amy can then pull Dave's changes from Main. Files that
were concurrently modified are automatically merged wherever possible using BitKeeper's
ProMerge technology (if manual merging is necessary, BitKeeper provides
advanced 3-way merge GUI tools).
Once Amy has merged, she can push her work to Main. A powerful feature
of BitKeeper is that all individual, incremental work is preserved with
a detailed audit trail of who did what. If Dave's work turned out to be bad,
good work from Amy (and from any other developer) that went into the merge
is retrievable. Other SCM solutions typically lose all of the incremental
work except that of the last person that merged and checked in.
Collaborating peer-to-peer
Unlike other SCM systems, BitKeeper enables developers to push and pull
changes peer-to-peer. This gives you the power to work collaboratively and
to leverage each others work without affecting unrelated groups. Organizations
implementing Scrum, Extreme Programming, or other agile development methods
can now encourage collaboration without anyone leaving a version control
environment. People's work is also more likely to be tested and peer reviewed,
improving software quality.
On-demand branching
BitKeeper enables a workflow that allows organizations to adaptively
divide and conquer projects according to customer priorities. Suppose
Dave's feature suddenly turns into a customer priority that requires
additional resources. Dave's workspace can be quickly cloned into
a staging area that additional developers can work against. Updates,
merges, and tests are still sandboxed within the group. BitKeeper's
advanced merge capabilities also make co-ordinating updates coming
down from Main and coming up from Dave's team easy to manage.
I'm ready to evaluate BitKeeper...
Advantages
-
Increased Productivity
BitKeeper was designed to simplify source management tasks and
provide an excellent infrastructure for debugging and reviewing
code.
-
Reduce human error
BitKeeper updates are transactional.
BitKeeper runs repository level integrity checks which catch
problems immediately, while there is still time to fix them.
-
Reproducibility
Complex software projects with multiple developers require
software configuration management tools that allow for the
accurate reproducibility of past and present information.
Because BitKeeper supports the concept of a logical unit of work
where each unit is immutable -- it cannot change but can be added
to -- BitKeeper produces a completely reproducible repository for
any moment in time.
BitKeeper manages the development process so that every phase of a
project can be recreated at a future point in time.
Not only are file contents revisioned, but such information as
permissions and file deletion events.
-
Accountability
Because the repositories are completely reproducible at any point
in time, it's easy to find out who made what changes, and what
other files were changed at the same time.
Debugging becomes a much more efficient and less frustrating
endeavor with BitKeeper.
-
Disconnected/Distributed Operations
Every user's work area contains the revision history files such
that all work may proceed without any interaction with the main
repository, so it's not a necessity to have a TCP connection
between all of the systems all of the time.
Each work area is a fully functioning repository.
Joe can clone a copy of a repository to his laptop and have 100%
functionality while disconnected, on an airplane, at a conference,
etc.
BitKeeper includes tools that propagate changes from one
repository to another.
-
Scalable
A common problem with most configuration management systems is
they don't scale.
They all work great for 1-5 developers, but they tend to fall
apart when you have 1000 developers.
BitKeeper's architecture is inherently scalable, so what works for
five developers works equally well for 1,000 or 10,000.
-
Excellent merging tools
BitKeeper has unique merging algorithms that significantly reduce
the chance of merge conflicts when compared to other tools.
In the rare event of a merge conflict, BitKeeper includes a best
in class
three-way file merge
which makes merging as easy as pointing and clicking.
Customers have reported as much as a 18 times reduction in merge
time using these tools.
-
Reliability
Multiple checksums on both the content and revision history of a
file ensure that corruption due to hardware and operating system
problems are caught early and without propagating through the SCM
system.
In addition, the distributed nature of BitKeeper repositories
eliminates the single point of failure mode that can occur in
client-server SCM systems.
Platforms
BitKeeper works well on all of the supported platforms, with the
only differences being either performance related (due to the file
system) or operating system related (no symbolic links on Win32
platforms).
When asked, we tend to recommend Linux as the platform of choice;
BitKeeper makes extensive use of the file system and Linux has the
the best file system for this application.
The list of supported platforms is currently:
-
AIX 4.1.5 and later on PPC
-
FreeBSD 2.x, 3.x, 4.x, 5.x and 6.x on x86
-
HPUX 11.11 and later on PARISC
-
IRIX 6.5 and later on MIPS (to be phased out in bk-5.0)
-
Linux/Alpha (64bit)
-
Linux/IA64 (Intel 64bit Itanium)
-
Linux/MIPS (Sibyte)
-
Linux/PARISC (HP RISC platforms)
-
Linux/PPC
-
Linux/S390
-
Linux/SPARC
-
Linux/x86 (x86, AMD, Cyrix, etc)
-
Linux/x86-64 (AMD Opterons, etc)
-
MacOS X on PPC and x86
-
NetBSD 1.5 on x86
-
OpenBSD 2.7 on x86
-
SCO OpenServer Release 5 on x86
-
Solaris 5.6 and later on SPARC
-
Solaris 5.7 and later on x86
-
Windows 2000
-
Windows 2000 Server
-
Windows 2000 Advanced Server
-
Windows 2003
-
Windows XP
-
Windows Vista (32 bit only)
Please contact us for more information if your platform is not
currently supported.
We will add support for any POSIX compliant platform for a 50 or
more seat sale provided that the system is readily available and
is not prohibitively expensive.
Tru64 Unix on Alpha support was phased out due to lack of
commercial interest but could be brought back for a commercial
customer.
Evaluation
This section is a hyper link to here.
Customers
BitKeeper is used by many of today's industry leaders covering a wide
range of markets. Listed below are just a few examples of companies
that have realized the benefits of BitKeeper's innovative technology.
Comparisons
We've gone through the more popular SCM systems available today
and contrasted them with BitKeeper based on our research and
feedback from customers who have used both BitKeeper and one or
more of the other systems.
If your favorite system isn't listed, let us know and we'll try
and add it.
| FEATURE |
OTHER SCM |
BITKEEPER |
BENEFIT |
| Inherently reliable through replication |
No |
Yes |
No downtime. Your developers spend their time developing your product, instead of waiting on a server rebuild. |
| File/directory renaming |
Rarely |
Yes |
Increased productivity through well organized source base. |
| BK/ProMerge (tm) |
No |
Yes |
Accurately reduces the number of merge conflicts, eases resolution of remaining conflicts. |
| True distributed system |
No |
Yes |
100% productivity at geographically distributed sites at all times, with no loss of functionality or performance. Any user may modify any file on any branch at any time, without restriction. |
| Powerful GUI tools |
No |
Yes |
Dramatically simplifies debugging, easier merges, improves check in comments. |
| All changes are reproducible snapshots |
No |
Yes |
Easily remove bad changes, aids in debugging, aids in release management. |
| Web project tracking |
Maybe |
Yes |
Allows management to track projects and estimate release dates. |
| Optimal performance for all users, local or remote |
No |
Yes |
Database replication means all developers, local or remote, get optimal performance. BitKeeper works well even over low bandwidth, high latency links such as modem or satellite links. |
| Disconnected (laptop) |
No |
Yes |
Productivity while traveling, at home, at remote offices with partial/slow network connectivity. |
| Peer-to-peer architecture |
No |
Yes |
Work may flow in any direction, including "sideways" between two developers without involving a "master" copy. |
| Painless upgrades |
No |
Yes |
Upgrading server does not affect developers. |
| Cross platform GUI |
Rarely |
Yes |
Increased productivity, no retraining. |
| Scripting |
Maybe |
Yes |
Easily customizable to your environment. |
| Customizable reports |
Rarely |
Yes |
Accountability and status to/for managers. |
| Automatic integrity checks |
No |
Yes |
Catches hardware/software problems promptly, while replicas are still available. |
| Active roadmap |
Maybe |
Yes |
BitKeeper is actively developed by a world class development team. Follow on products for bug tracking, sales tracking, project management, project hosting are all actively being developed. |
CVS
-
CVS is in widespread use, mainly because it is free.
It works fairly well for simple tasks, it's better than just using
RCS.
It has problems as the development effort gets large.
-
CVS has a single repository model.
Each work area is clear text only which means no revision control
in the work area during development.
-
No staging areas to protect the main source tree.
With CVS, everyone checks into the same place and if someone
breaks the tree, it's broken for everyone.
With BitKeeper, you can put a staging area between each group of
developers and the main integration tree, thereby protecting the
main tree from bad checkins.
Anyone who has lived through a change that broke the build can see
the value of staging areas.
-
CVS loses information every time there is parallel development
because you are forced to merge before you check in if someone
else checked in first.
The state of your workspace before the merge is lost forever.
Another way to say this is that if there is N-way parallel
development, CVS loses N-1 events.
-
Merging in CVS is primitive at best.
-
Branch management in CVS is a nightmare.
-
CVS has no change sets, i.e., no atomic commits of changes which
span files.
-
CVS has no integrity checker which means files can be silently
corrupted and you will never know until you try and roll
backwards.
-
CVS has no rename support.
-
CVS was based on RCS and still has RCS' limitations.
-
On the plus side, CVS is free, works well enough for some
development projects, and CVS repositories are easily converted to
BitKeeper.
If you can't afford a good source management product, use CVS,
we'll help you migrate off of it when the time comes.
BitKeeper/CVS Feature Comparison
Download the
BitKeeper/CVS Feature Comparison matrix
(pdf)
| Feature |
BK/Pro |
CVS |
Benefit |
| Atomic ChangeSets |
Yes |
No |
- Every change is a reproducible snap shot
- Aids in debugging and release management
|
| Graphical checkin tool |
Yes |
No |
- Graphical tool for file and changeset checkins which promotes more useful comments to speed up development processes and debugging
|
| Dynamic branching |
Yes |
No |
- Any workspace can be turned into a branch
- Advanced planning for branching is not needed
|
| Pro Merge Technology |
Yes |
No |
- Most accurate automerge available
- Only merge each change once
|
| Accurate handling of renames |
Always |
No |
- Increased productivity through a well organized source base
|
| Peer-to-peer architecture |
Yes |
No |
- Supports any workflow for enhanced quality control
- Supports the rapid open source style of development
|
| Complete local history |
Yes |
No |
- Your developers can keep working even when your server or network doesn't
- Inherent reliability through replication
|
| True parallel development |
Yes |
No |
- Enhanced productivity
- Faster time to market
|
| Multi-site development |
True |
No |
- BitKeeper provides 100% functionality and productivity at all distributed sites
|
| Mobile/Off-network functionality |
Yes |
No |
- Increased development productivity by allowing your developers to work while travelling, while at remote locations, while at customer sites, or without a network
|
| Pre-event triggers |
Yes |
Weak |
- Ability to qualify events prior to changes which enhances compliance to your development policies
|
| Post-event triggers |
Yes |
Weak |
- Supports notification of events and automated secondary operations which provides easier process management
|
| Replicated repositories |
Yes |
No |
- Provides enhanced reliability along with the ability to perform transparent, automatic backups
|
| Automatic integrity checks |
Yes |
No |
- Detects corruptions indicating potential hardware and software problems saving time and money associated with unplanned downtime
|
| Accurate recording of all history |
Yes |
No |
- Accountability: Easy to find Who did What When
- Provides a complete picture of your parallel development
- Speeds of debugging process
|
| Minimal Administration |
Yes |
Varies |
- Head count can be used for development rather than taking care of the SCM system
|
| Minimal hardware requirements |
Yes |
Varies |
- No need to purchase additional hardware
- No requirement for large, expensive server
|
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.
BitKeeper/Subversion Feature Comparison Matrix
Download
BitKeeper/Subversion Feature Comparison matrix
(pdf)
| Feature |
BK/Pro |
Subversion |
Benefit |
| Atomic ChangeSets |
Yes |
No |
- Every change is a reproducible snap shot
- Aids in debugging and release management
|
| Graphical checkin tool |
Yes |
No, done through IDE |
- Graphical tool for file and changeset checkins which promotes more useful comments to speed up development processes and debugging
|
| Dynamic branching |
Yes |
No |
- Any workspace can be turned into a branch
- Advanced planning for branching is not needed
|
| Pro Merge Technology |
Yes |
No |
- Most accurate automerge available
- Only merge each change once
|
| Accurate handling of renames |
Always |
No |
- Increased productivity through a well organized source base
|
| Peer-to-peer architecture |
Yes |
No |
- Supports any workflow for enhanced quality control
- Supports the rapid open source style of development
|
| Complete local history |
Yes |
No |
- Your developers can keep working even when your server or network doesn't
- Inherent reliability through replication
|
| True parallel development |
Yes |
No |
- Enhanced productivity
- Faster time to market
|
| Multi-site development |
True |
No |
- BitKeeper provides 100% functionality and productivity at all distributed sites
|
| Mobile/Off-network functionality |
Yes |
No |
- Increased development productivity by allowing your developers to work while travelling, while at remote locations, while at customer sites, or without a network
|
| Pre-event triggers |
Yes |
Yes |
- Ability to qualify events prior to changes which enhances compliance to your development policies
|
| Post-event triggers |
Yes |
Yes |
- Supports notification of events and automated secondary operations which provides easier process management
|
| Replicated repositories |
Yes |
No |
- Provides enhanced reliability along with the ability to perform transparent, automatic backups
|
| Automatic integrity checks |
Yes |
No |
- Detects corruptions indicating potential hardware and software problems saving time and money associated with unplanned downtime
|
| Accurate recording of all history |
Yes |
No |
- Accountability: Easy to find Who did What When
- Provides a complete picture of your parallel development
- Speeds of debugging process
|
| Minimal Administration |
Yes |
No |
- Head count can be used for development rather than taking care of the SCM system
|
| Minimal hardware requirements |
Yes |
No |
- No need to purchase additional hardware
- No requirement for large, expensive server
|
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.
BitKeeper/Perforce Feature Comparison Matrix
Download
BitKeeper/Perforce Feature Comparison matrix
(pdf)
| Feature |
BK/Pro |
Perforce |
Benefit |
| Atomic ChangeSets |
Yes |
No |
- Every change is a reproducible snap shot
- Aids in debugging and release management
|
| Graphical checkin tool |
Yes |
Weak |
- Graphical tool for file and changeset checkins which promotes more useful comments to speed up development processes and debugging
|
| Dynamic branching |
Yes |
No |
- Any workspace can be turned into a branch
- Advanced planning for branching is not needed
|
| Pro Merge Technology |
Yes |
No |
- Most accurate automerge available
- Only merge each change once
|
| Accurate handling of renames |
Always |
Rarely |
- Increased productivity through a well organized source base
|
| Peer-to-peer architecture |
Yes |
No |
- Supports any workflow for enhanced quality control
- Supports the rapid open source style of development
|
| Complete local history |
Yes |
No |
- Your developers can keep working even when your server or network doesn't
- Inherent reliability through replication
|
| True parallel development |
Yes |
No |
- Enhanced productivity
- Faster time to market
|
| Multi-site development |
True |
Simulated |
- BitKeeper provides 100% functionality and productivity at all distributed sites
- Perforce provides partial functionality through a cache
|
| Mobile/Off-network functionality |
Yes |
No |
- Increased development productivity by allowing your developers to work while travelling, while at remote locations, while at customer sites, or without a network
|
| Dynamic Licensing |
Yes |
No |
- Provides developers the flexibility of checking in from any host or domain and read-only users can access data without tying up a license.
- This model can save you 25% - 50% of licensing costs
|
| Pre-event triggers |
Yes |
Limited |
- Ability to qualify events prior to changes which enhances compliance to your development policies
|
| Post-event triggers |
Yes |
Limited |
- Supports notification of events and automated secondary operations which provides easier process management
|
| Replicated repositories |
Yes |
No |
- Provides enhanced reliability along with the ability to perform transparent, automatic backups
|
| Automatic integrity checks |
Yes |
No |
- Detects corruptions indicating potential hardware and software problems saving time and money associated with unplanned downtime
|
| Accurate recording of all history |
Yes |
No |
- Accountability: Easy to find Who did What When
- Provides a complete picture of your parallel development
- Speeds up debugging process
|
| Minimal Administration |
Yes |
Varies |
- Headcount can be used for doing development rather than upkeep of the SCM system
|
| Minimal hardware requirements |
Yes |
Varies |
- No need to purchase additional hardware
- No requirements for large, expensive server
|
Perforce is a trademark of Perforce Software, Inc.
ClearCase
-
ClearCase is integrated into the operating system as a file
system.
Experience has shown that this can be problematic each time the
operating system is upgraded.
-
ClearCase is slow for many common operations when compared against
a local filesystem.
-
ClearCase is quite resource hungry - it is not uncommon to spend
as much as $300,000 for a large SMP server to serve up 20
developers.
A $2000 PC can (and
does)
do the same job with BitKeeper.
-
ClearCase is expensive in more ways than just seat costs.
The hardware and administrative costs to run a ClearCase server
can dwarf the seat costs.
It is common to allocate a full time administrator to manage the
ClearCase server and software.
-
The ClearCase multisite feature is an attempt to decentralize a
centralized system and it doesn't work as well as a truly
distributed system.
The basic idea is that each site gets a branch, that branch is
writable by that site only, the other site's branches are read
only.
BitKeeper has no such restrictions, all sites can work on the same
branch at the same time.
-
BitKeeper improves debugging efficiency of developers through
changesets;
it is trivial to go from a line of code to the changeset which
introduced that line.
-
Development managers can perform better code reviews with
BitKeeper.
-
Management can easily track project progress through the BK/Web
interface.
-
BitKeeper is easier for administrative staff to learn and support.
-
BitKeeper is more reliable - all repositories are database
replicas.
-
BitKeeper allows full-development efficiency at remote sites, with
no loss of performance or functionality.
-
BitKeeper saves money through dramatically reduced hardware
requirements.
-
BitKeeper is fast - maintains single user performance levels.
-
Summary: ClearCase is the mature market leader, but has a
centralized architecture which implies many limitations.
BitKeeper has a proven distributed, replicated architecture
without those same limitations.
Total cost of ownership with ClearCase can easily exceed 5 times
that of BitKeeper for the same development effort.
BitKeeper/ClearCase Feature Comparison Matrix
Download
BitKeeper/ClearCase Feature Comparison matrix
(pdf)
| Feature |
BK/Pro |
ClearCase |
Benefit |
| Atomic ChangeSets |
Yes |
No |
- Every change is a reproducible snap shot
- Aids in debugging and release management
|
| Graphical checkin tool |
Yes |
Yes |
- Graphical tool for file and changeset checkins which promotes more useful comments to speed up development processes and debugging
|
| Dynamic branching |
Yes |
No |
- Any workspace can be turned into a branch
- Advanced planning for branching is unneeded
|
| Pro Merge Technology |
Yes |
No |
- Most accurate automerge available
- Only merge each change once
|
| Accurate handling of renames |
Yes |
Yes |
- Increased productivity through a well organized source base
|
| Peer-to-peer architecture |
Yes |
No |
- Supports any workflow for enhanced quality control
- Supports the rapid open source style of development
|
| Complete local history |
Yes |
No |
- Your developers can keep working even when your server or network doesn't
- Inherent reliability through replication
|
| True parallel development |
Yes, trivial |
Yes, complex |
- Enhanced productivity
- Faster time to market
|
| Multi-site development |
Yes, included |
Yes, add on |
- BitKeeper provides 100% functionality and productivity at all distributed sites
- ClearCase's add on is a high cost, high admin band-aid to decentralize a centralized system
|
| Mobile/Off-network functionality |
Yes |
No |
- Increased development productivity by allowing your developers to work while traveling, while at remote locations, while at customer sites, or without a network
|
| Dynamic Licensing |
Yes |
No |
- Provides developers the flexibility of checking in from any host or domain
- Read-only users can access data without tying up a license
- Developers never have to wait for a license to become available
|
| Pre-event triggers |
Yes |
Yes |
- Ability to qualify events prior to changes which enhances compliance to your development policies
|
| Post-event triggers |
Yes |
Yes |
- Supports notification of events and automated secondary operations which provides easier process management
|
| Replicated repositories |
Yes |
Limited, with multisite |
- Provides enhanced reliability along with the ability to perform transparent, automatic backups
- ClearCase provides a multi site add on which does replicate the repository data, but with a very high admin overhead
|
| Automatic integrity checks |
Yes |
No |
- Detects corruptions indicating potential hardware
and software problems saving time and money associated with unplanned downtime
|
| Accurate recording of all history |
Yes |
No |
- Accountability: Easy to find Who did What When
- Provides a complete picture of your parallel development
- Speeds up debugging process
|
| Minimal Administration |
Yes |
No |
- Convert at least one headcount from every development site from administrator to developer
- Saves the cost of one full time admin at every development site
|
| Minimal hardware requirements |
Yes |
No |
- No need to purchase additional hardware
- No requirement for large, expensive server
|
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.
BitKeeper/VSS Feature Comparison
Download
BitKeeper/VSS Feature Comparison matrix
(pdf)
| Feature |
BK/Pro |
VSS |
Benefit |
| Atomic ChangeSets |
Yes |
No |
- Every change is a reproducible snap shot
- Aids in debugging and release management
|
| Graphical checkin tool |
Yes |
Limited |
- Graphical tool for file and changeset checkins which promotes more useful comments to speed up development processes and debugging
|
| Dynamic branching |
Yes |
No |
- Any workspace can be turned into a branch
- Advanced planning for branching is not needed
|
| Pro Merge Technology |
Yes |
No |
- Most accurate automerge available
- Only merge each change once
|
| Accurate handling of renames |
Always |
No |
- Increased productivity through a well organized source base
|
| Peer-to-peer architecture |
Yes |
No |
- Supports any workflow for enhanced quality control
- Supports the rapid open source style of development
|
| Complete local history |
Yes |
No |
- Your developers can keep working even when your server or network doesn't
- Inherent reliability through replication
|
| True parallel development |
Yes |
No |
- Enhanced productivity
- Faster time to market
|
| Multi-site development |
True |
No |
- BitKeeper provides 100% functionality and productivity at all distributed sites
|
| Mobile/Off-network functionality |
Yes |
No |
- Increased development productivity by allowing your developers to work while travelling, while at remote locations, while at customer sites, or without a network
|
| Pre-event triggers |
Yes |
No |
- Ability to qualify events prior to changes which enhances compliance to your development policies
|
| Post-event triggers |
Yes |
No |
- Supports notification of events and automated secondary operations which provides easier process management
|
| Replicated repositories |
Yes |
No |
- Provides enhanced reliability along with the ability to perform transparent, automatic backups
|
| Automatic integrity checks |
Yes |
No |
- Detects corruptions indicating potential hardware and software problems saving time and money associated with unplanned downtime
|
| Accurate recording of all history |
Yes |
No |
- Accountability: Easy to find Who did What When
- Provides a complete picture of your parallel development
- Speeds of debugging process
|
| Minimal Administration |
Yes |
Varies |
- Head count can be used for development rather than taking care of the SCM system
|
| Minimal hardware requirements |
Yes |
Varies |
- No need to purchase additional hardware
- No requirement for large, expensive server
|
RCS
RCS is not an SCM system, it is a file based system.
However, many commercial systems use the inferior RCS file format
so we felt it was worth having RCS in the comparisons.
-
RCS has no checksum.
RCS files can get silently corrupted and RCS will never notice
unless you happen to ask for a delta that is part of the corrupted
area of the file.
Because of the way RCS is designed, it is unlikely to ever notice
a problem until too late.
BitKeeper checksums the entire file as well as each delta and
verifies the checksum on each operation.
-
Lack of compression.
BitKeeper supports compressed contents.
The administrative part of the file (typically less than 5% of the
file size) is uncompressed;
the rest may be compressed to gain back disk space and use less
disk/network bandwidth.
-
RCS has no rename support.
BitKeeper records pathnames with the deltas so that files may be
moved around easily without losing track of where they once lived.
Sales
This section gives details about how to purchase BitMover's products.
We offer a free, no obligation evaluation of our products and the
evaluation can be conducted without any impact to your existing
history or environment.
We offer a range of
product purchasing options
that can be tailored to your needs, whether you are a startup or
a global enterprise. Licenses can be purchased or leased on an
annual basis, with support and upgrades included in the annual
licenses. Also, you can take advantage of various
incentive programs
that will decrease both risk and cost in your buying decision.
To request a quote or an evaluation key please fill out the
license request form.
For information and assistance, please send a query to
sales@bitmover.com
or call BitMover at 888-401-8808.
Evaluation
This section is a hyper link to here.
Do you need BK?
SCM systems are often a productivity bottleneck.
Inexpensive entry level systems don't solve the problems you need
solved.
Traditional high end systems are resource and administration
intensive.
BitKeeper is light, fast, and exceptionally simple to use, yet it
offers advanced features not found in even the most expensive
traditional systems.
-
Productivity
BitKeeper is a developer's tool, it puts more power in the hands of the
developer while allowing enough structure to manage your projects.
BitKeeper's peer-to-peer and replicated architecture spreads
the load over all your machines, significantly reducing server
and network bottlenecks.
BitKeeper provides a full suite of features to speed up all of the operations
that your developers use most frequently.
-
Reliability
BitKeeper performs regular consistency checks without having to take
your system offline.
BitKeeper's architecture allows your developers to continue working locally
with full functionality even if your server goes down or you experience
a network outage.
And it provides inherent backups through replication.
It is possible and easy to guarantee 24x7 uptime with BitKeeper.
-
Flexibility
BitKeeper is a peer-to-peer system, that seamlessly supports
customized work flows.
Whether a small or large shop, BitKeeper can adapt to your
development process and then grow with you as your needs change.
BitKeeper's Delta Development model epitomizes the flexibility and
scalability that is achievable with our peer-to-peer architecture.
-
Total cost of ownership
The total cost of an SCM solution goes far beyond the price of the
software. With many tools, the real cost lies in administration,
hardware, support, and professional services. With BitKeeper those
costs are negligible.
The replicated nature of BitKeeper means that a PC will work fine
and there is no need for full-time admins.
A
small and cheap PC
can easily support thousands of developers.
It would cost more than a hundred times as much to do the same
thing with other SCM solutions.
-
Support
Our support is without equal in the industry, we are responsive
and will work with you to deploy BitKeeper effectively,
at no extra charge. BitMover does not have multiple layers of
support, you can talk directly to an engineer that can solve your
issues.
Our customers frequently describe our support as the best they've
ever received.
-
Remote/distributed development
With centralized client/server SCM systems, all remote people and teams
suffer.
BitKeeper is a peer-to-peer system based on a replicated database.
All teams become local and enjoy local performance in a replicated
system.
-
Merging
BitKeeper's ProMerge has best-in-class merge algorithms and merge tools
which reduce merge time to 1/10th of the time required by other
tools. Many customers claim that the man hours savings in merging
alone more than covers the software cost.
-
Reproducibility
BitKeeper guarantees 100% accurate rollback of all file contents,
names, and permissions without requiring any forethought on your
part.
While other systems require that you remember to tag the tree,
BitKeeper has no such requirement;
all changes are potential rollback points.
-
Reviewing and debugging code
BitKeeper maintains more history detail with more accuracy than
any other tool currently available. We also have a suite of tools
that allow you to get a quick picture of your development history
at a high level and instantly delve into specific detail.
-
Renames
BitKeeper gets this right, files may be renamed at any time, in
any work space, and the renames are handled correctly in all
cases.
If you are interested in enjoying the benefits of BitKeeper please
request a quote or an evaluation key through our online
request form.
For information and assistance, you may also send a query to
sales@bitmover.com
or call BitMover at 888-401-8808.
How to buy
BitKeeper prices depend on a variety of factors including which
products you choose, whether you choose to lease or buy, and the
number of licenses you need.
The total cost of SCM includes more than just seat price.
The full set of costs are discussed in our
total cost of ownership
section which demonstrates how BitKeeper can be significantly less
expensive than any other offering, free or commercial.
We offer two different methods for licensing BitKeeper, allowing you to
choose which method best fits your business requirements.
Buy option:
this is the traditional way of purchasing software, you pay a one
time fee and have the right to use that version of the software
indefinitely.
This model includes the first year of support and maintenance,
with additional years available for a yearly fee.
Lease option:
this is the new preferred model in the software industry.
Leasing has become very attractive with software buyers who see
the advantage of smaller annual payments, included support, and
included upgrades.
This means you can always get the latest version without having to
retire your old software and buy it again every year or two.
This option has proven to be quite popular with our customers
because it is substantially less than the purchase price and is
paid annually.
BitKeeper can be purchased in the following packages:
To request a quote or an evaluation key, please fill out the
license request form.
For information and assistance, please send a query to
sales@bitmover.com
or call BitMover at 888-401-8808.
Cost of ownership
The total cost of ownership of any SCM product needs to be
balanced against the benefits in order to make an informed
purchasing decision.
While it is usual to consider only the software costs, doing so
can lead to an inaccurate view, resulting in unpleasant surprises
down the road.
The real cost of ownership is the sum of:
-
Licensing costs
-
Hardware costs
-
Human costs
All of these need to be assessed in order to see the true cost of
any system.
For some products, it turns out that the people and hardware costs
dwarf the cost of the software.
The following chart quickly illustrates hidden costs of other SCM
products.
| COSTS |
OTHER SCM |
BITKEEPER |
| Software licenses |
$-$$$$ |
$$$ |
| Setup |
$$-$$$$$ |
$ |
| Hardware |
$$$-$$$$$ |
$ |
| Administration |
$$-$$$$$ |
$ |
| Third party databases (if needed) |
$$$$ |
0 |
Licensing costs.
Paid BitKeeper licenses are needed for each person who uses the
software to make changes of any kind.
Read-only users (people browsing the source, tracking progress,
doing builds, etc.) still need a license but there is no charge
for that license.
In general, our software delivers productivity increases and time
savings far in excess of the annual lease investment.
Hardware costs.
Software requires hardware, and SCM software has traditionally
required a great deal of hardware.
Consider that virtually all other SCM systems have a centralized
design where the SCM system runs on a single server.
The performance of that server is a function of the server itself
and the number of concurrent users.
If there is only one user, a modest server will perform quite
well, but as the number of users increases, the hardware must also
be improved or performance becomes unacceptable.
Unfortunately, the cost of performance is not linear.
A system which is twice as fast is rarely only twice as costly,
and a system which is ten times as fast is always much more than
ten times as much.
The problem is obvious, a centralized SCM system will add hardware
costs at what can be an exponential rate as the number of users
increases.
This translates into reasonable costs for 5-10 users and
unreasonable costs for 100-1000 users.
BitKeeper does not have this problem because of its distributed
model.
The main repository is rarely used, work takes place in the child
or grandchild repositories and then fans into the main repository.
This model means that the hardware costs can be spread over a set
of
inexpensive PCs
rather than a $300,000 SMP machine.
BitMover hosts repositories used by thousands of developers on a
single inexpensive server.
Human costs.
Many SCM systems have traditionally required an administrator for
every 10-20 users.
These administrators are critical when the SCM is a centralized
single point of failure.
If an administrator costs $200,000 (salary, benefits, and other
overhead) and one is needed for every 20 users, that is a
not-so-hidden additional cost of $10,000/user/year.
One may argue that a well run installation could do better,
perhaps one administrator per 100 users, but that is still an
additional $2,000/user/year.
BitKeeper eliminates the need for an administrator, it has no
single point of failure.
The savings realized by not needing an administrator to nursemaid
the SCM server will easily cover 100% of the cost of BitKeeper.
Note that an administrator is not the same as a project lead who
defines and controls policy in the repositories;
all development efforts of any size will need people in that role
and no SCM system can remove that requirement.
An administrator is the person who makes sure that the hardware
and the software is working, the repositories are backed up, etc.
The distributed nature of BitKeeper removes the need for such a
person.
Incentives
|
The BitKeeper Challenge
|
|
| |
Full refund if you don't see value. No other SCM product can offer this kind of guarantee.
Seeing the value.
BitKeeper's customers consistently achieve productivity gains that far exceed their initial
expectations and we're confident that you will too. However, we at BitMover believe that there is no substitute for using
a product in-house over the course of a year to really understand its benefits. Improving developer workflow and
productivity, decreasing hardware and administration costs, and eliminating problems with slow networks or server
downtime will quickly add up in savings unlike any other solution.
Full refund.
We are so confident that you will achieve significant ROI with BitKeeper that we will fully
refund your license fee after the first year if you do not see the value and elect to discontinue use. Check the
competition to see if they're as confident about their SCM tool.
Minimal to zero risk.
If you choose to migrate off of BitKeeper after completing the challenge, we will
help you export your BitKeeper repository into a standard SCM tool. Since BitKeeper maintains more metadata than
other SCM tools, data that you would have collected during the course of the year with another SCM tool will be preserved.
How to qualify.
The BK challenge is available to new customers that sign on for a minimum of 10 developer seats of
either BK/Pro or BK/Enterprise at the beginning of the first license year. The BitKeeper Test Drive and a one hour free
process consultation must also be completed within two weeks of receiving the evaluation key. Contact us to inquire about
additional details and how you can qualify.
|
  |
|
License Buffer
|
|
| |
Our customers find BitKeeper is so valuable that its use typically expands beyond the traditional developer. Support
engineers, part time developers, consultants, QA, and build engineers frequently demand BitKeeper and we'll help pay
for those users. For qualified customers we will provide 5 additional seats at no charge to cover expansion beyond
your core developers.
|
  |
|
Trade-In Program
|
|
| |
First time customers may qualify to trade in their old,
inefficient source management tool in order to offset up to 50% of the investment in BitKeeper.
Contact us for details.
|
  |
| |
Test drive
Thank you for trying BitKeeper!
The following demo will walk you through:
-
Installing BitKeeper
-
Creating your own workspace (cloning a repository)
-
Browsing the history of the repository using bk revtool
-
Searching, reviewing, and debugging
-
Updating a repository
-
Viewing the updates
-
Making your own changes
-
Merging your work with another person's work
You will need to type some commands and run some graphical tools.
You will see prompts like this:
 |
Command-line prompt: When you see this, type it in the shell.
|
 |
Graphical prompt: When you see this, do it in the BitKeeper GUI.
|
 |
Graphical prompt for Windows: When you see this, do it in the Windows GUI.
|
The demo was designed to be done in under 30 minutes.
Installation
In this section you will install the BitKeeper product.
If you have not
downloaded
BitKeeper you should request an evaluation key and download information now.
Once you have downloaded the software, continue with the
installation directions for your operating system.
Unix
The image you download is an executable file and your license keys
are imbedded in it. In case
your browser did not preserve the permissions, do:
 |
chmod +x installer_binary
|
Then run the installer:
 |
./installer_binary
|
The default is to run the graphical installer.
To run the command-line installer, set the destination directory on the
command line:
 |
./installer_binary destination_dir
|
Windows
The image you download is an executable file and your license keys
are embedded in it.
 |
Double-click on the x86-win32 icon.
You can safely use the defaults for all prompts.
|
Once BitKeeper is successfully installed, open a cmd window to run the demo:
 |
Start -> run -> cmd
|
Mac OSX
The image you download is an executable file and your license keys
are embedded in it.
You will need to run the executable from a terminal window.
In case your browser did not preserve the permissions, do:
 |
chmod +x installer_binary
|
Then run the installer:
 |
sudo su -
cd download-dir
./installer_binary
|
When prompted, enter your own password.
The default is to run the graphical installer.
To run the command-line installer, set the destination directory on the
command line:
 |
./installer_binary destination_dir
|
Cloning a repository
Cloning
is the term we use to describe the process of getting a personal
workspace.
Your workspace is your copy of both the source code and the
revision history.
You browse, modify, and check in changes to
your
workspace.
In the cloning section you will:
-
Clone a demo repository from bkbits.net to your local machine;
this repository will act as the "server" repository.
-
Clone a workspace from the "server" repository you cloned from bkbits.net.
Go to a directory or folder of your choice.
 |
mkdir BK
cd BK
bk clone http://bkdemo.bkbits.net/bk_demo my_parent
|
This creates a complete copy of the workspace in
BK/my_parent.
If it doesn't work, you might need to tell BitKeeper about your HTTP proxy,
which you can do by
 |
# shell
export http_proxy=http://your_proxy.your_company.com:80/
# cshell
setenv http_proxy http://your_proxy.your_company.com:80/
# Windows cmd.exe
set http_proxy=http://your_proxy.your_company.com:80/
|
For more information about methods of accessing repositories see
the manual page
 |
bk helptool url
|
Try this now and go to the next page after it is completed.
Cloning a child
Because the demo does not allow you to push changes back to
bkbits.net, you need to clone again so that you have a local parent
and child.
This also demonstrates same file system clones.
 |
bk clone my_parent bk_demo
|
You should now have a directory with two subdirectories: my_parent
and bk_demo.
There is a recorded relationship to the parent repositories.
bk_demo knows that it gets updates from
and sends updates to my_parent and my_parent knows it
gets updates from and sends updates to http://bkdemo.bkbits.net/bk_demo.
Using bk revtool
There are ways to browse the repository both graphically and via
the command line.
The following example shows you how to browse a repository and file
history using the graphical revision history browser, bk revtool.
Repository history is grouped by
changesets.
A changeset is a grouping of one or more changes to one or more
files, and it is what is propagated between BitKeeper
repositories.
Changesets are stored in a revision controlled file named
ChangeSet
and can be browsed graphically.
To do so:
 |
cd bk_demo
bk revtool
|
When in bk revtool, do:
 |
Click on Select Range.
Click on All Changes.
|
Things to notice:
-
invoking bk revtool with no file argument displays the history of the
entire repository, which is contained in the ChangeSet file.
-
the top window displays boxes representing changesets containing
the name of the person who made the changeset and the changeset
revision. Tagged changesets are highlighted with a yellow box.
-
the bottom window displays changeset information.
Repository history
 |
Left-click on the box that says "tytso 1.111" .
|
The bottom window contains the comments for the changed files
as well as the changeset comments.
 |
Left-click on rev 1.111.
Right-click on rev 1.114 (Cmd-click on Macintosh).
|
The bottom window now contains the comments for all changes from rev
1.111 and 1.114, inclusive.
 |
Scroll back to find the 1.107 changeset.
|
Things to notice:
-
The "branched" graph from node 1.107 represents parallel development.
-
All work is recorded, including branch points as separate nodes.
Each of these nodes is a reproducible snapshot of the repository.
Stay in bk revtool; on the next page you'll look at file history.
File history
 |
Click on node 1.114.
|
You should be looking at a changeset which has modifications to
pass2.c.
 |
Left-click (single-click) in the comments below the e2fsck/pass2.c file.
|
Another bk revtool appears; this one displays the history of pass2.c.
Revision 1.36 of pass2.c is the delta in the 1.114 changeset. bk revtool is
displaying the differences between the revision of interest (1.36) and its
parent (1.35). We can now explore this file further.
 |
Click Select Range.
Select All Changes.
|
To see the differences introduced by this delta:
 |
Left-click on 1.35 and right-click on 1.36 (Cmd-click on Macintosh).
|
The differences are displayed in the text window.
To see side by side differences with all the file context in a new
window:
 |
Click Difftool in the menu bar at the top of bk revtool.
In bk difftool, press the spacebar to walk through the diffs.
Press "p" to go to the previous diff.
Click Quit when done.
Click Quit in the bk revtool window that has ChangeSet in the title bar.
|
Stay in bk revtool with pass2.c in the title bar; on the next page
you'll do some searching.
Searching
Suppose that you are looking for a particular change in pass2.c.
Start by getting an annotated listing by
 |
Double-click on a node in the graph; let's choose 1.35.
|
You should see lines like
tytso 1.1 /*
tytso 1.1 * pass2.c --- check directory structure
tytso 1.1 *
The first field is the user who added that line, the second field
is the revision in which that line was added or changed, and the
rest is the line content.
Suppose that you were trying to track down a bug in symlink handling.
You know that the problem has something to do with a function with
pass1_check
in its name.
To find this
 |
Press "/" and notice that the focus is in the search window at the bottom.
Type in "pass1_check" and press "Enter".
That's not the right one; press "n".
Press "n" exactly 3 more times.
|
That's the one you want.
But you remember it being different so you would like to see what
it was like before this.
 |
Left-click on the line containing e2fsck_pass1_check_symlink.
|
Notice that the highlighted node in the graph is now the one
corresponding to the line you just clicked.
To see the changes for this revision,
 |
Press "d".
|
Repeat the search process to find the call to e2fsck_pass1_check_symlink:
 |
Press "/".
Type in "pass1" and press Enter.
Press "n".
Left-click on the line with pass1 highlighted.
|
Stay in bk revtool; on the next page you'll look at the changeset
that added that line.
Viewing a changeset
You should be on revision 1.34 in the history of pass2.c; if not
go click on that.
Now that you have found the version of the line you want, you might
want more information about what was happening when this change
was made.
This information can be helpful in tracking down the root cause of
a bug.
 |
Click on View Changeset at the top of bk revtool.
|
A new window, labeled Cset Tool, should appear.
This window has 4 panes.
-
The top left pane is the list of files in this changeset; you can
click on a file to make it active.
-
The bottom two windows show the before and after versions of the
active file.
You can move through the diffs by pressing the spacebar.
-
The top right file has the changeset checkin comments followed by
the checkin comments for the active file.
Browse around in the changeset viewer. Try clicking the files,
moving through diffs, etc.
 |
When you are done, click Quit in all BitKeeper windows.
|
At this point you should now be familiar with viewing repository and file
revision history using bk revtool.
If you would like to use command-line tools to browse history, please
read the help pages for bk changes and bk log:
 |
bk help changes
bk help log
|
Updating your repository
Next, you will update your repository using bk pull.
-
The first pull will be from the parent and will have no updates
-
The second pull will be from an alternate repository and will have updates
The bk pull command can be used with or without specifying a BitKeeper URL.
Using bk pull without a URL argument pulls from the parent. With a
URL, BitKeeper pulls from the repository specified by the URL.
By default, the parent is the repository from which the current repository
was cloned.
 |
bk pull
|
It should have told you there was nothing to pull, which is
correct; that repository has not changed.
Let's go pull from a different repository which does have changes:
 |
bk pull http://bkdemo.bkbits.net/bk_demo1
|
You now have learned how to get updates from the parent repository or an
alternative repository.
Go on to the next page to make your own changes.
Making changes
In this section you will learn about and become familiar with
-
file modes and checking out files for editting
-
checking in both modified and new files
-
creating changesets
-
viewing the new changes
Checkouts
Before you actually make any changes, it is important to get
acquainted with how to check out files in BitKeeper.
Cleaning a directory
 |
cd e2fsck
|
Notice the directory is populated with files.
Now do:
 |
bk clean
|
Notice that the files are now gone.
The SCCS directory is where the revision histories for the files
in the directory reside.
On Windows the SCCS directory is hidden by default.
Checking out
There are two modes for checked out files in BitKeeper: read-only
mode and read/write mode.
To check out (or get) the files in read-only mode do:
 |
bk co
|
Notice that the directory is now populated.
Now check out the files in read/write mode:
 |
bk edit
|
Notice that the files are now read/write capable and thus can be
modified.
To put the repository back in its original state, do:
 |
bk clean
bk co
|
Checkout Modes
By default, BitKeeper operates in a "clean" checkout mode such
that all files must be explicitly checked out.
It can also run in other checkout modes: get mode and edit mode.
The repositories you have cloned for this demo run in checkout:get
mode and consequently all files in the repository are checked out
in read-only mode.
If you run in checkout:edit mode, all files in the repository are
checked out and can be modified.
Modifying a file
Please do the following modification to recovery.c:
 |
bk edit recovery.c
Edit recovery.c in a text editor.
Change all instances of "jread" to "Jread".
|
Creating a file
Create a new file:
 |
echo "/* New File */" > foo.c
|
Notice that you did not tell BitKeeper that this file needs to be revision
controlled; you'll do that later.
Viewing the changes
Often it is useful to see what changes have been made that haven't
been checked in yet.
You can use bk difftool or bk diffs to view differences.
Try the command line first; you should see the jread changes:
 |
bk diffs
|
And to see which files are not yet under BitKeeper control:
 |
bk extras
|
Then try the graphical tool:
 |
bk difftool
|
As with most BitKeeper graphical tools, you can use the "n" key to get to
the next diff and the "p" key to get to the previous diff.
bk difftool displays the differences between the last rev and the
modified versions of the file if run without options and the file
argument is a modified file.
With no arguments, it shows diffs for all modified files in
the current directory.
 |
Click Quit in bk difftool.
|
Checking in changes
Checking in files and creating a changeset can be done via the command line
or with bk citool, the graphical check-in tool.
We recommend using bk citool because it shows the changes
made to each file which improves the quality of the comments.
Steps for the graphical tool are shown first followed by steps for another
file edit and the command-line check-in.
Using bk citool:
 |
bk citool
|
 |
Add comments about the changes in the middle window.
Click on the icon next to foo.c to add this file to the repository.
Click on ChangeSet.
Add comments about the ChangeSet in the middle window.
Click on the Commit box at the right.
Click on the Commit box again to confirm you are done.
|
You have now checked in your changes, added the new file foo.c, and
grouped these changes into a changeset. Next you will check in changes
using the command line:
 |
echo foo > bar.c
bk new bar.c
bk edit foo.c
echo "This is file foo.c" >> foo.c
bk ci -y"These are the checkin comments" foo.c
bk commit -y"These are the changeset comments"
|
To see the changes you've just made:
 |
bk revtool
|
 |
Double-click on the box containing "your_login 1.125".
In the bottom window, click on the line under "e2fsck/recovery.c".
|
The history of the recovery.c file is shown in another bk revtool
window. You can use bk revtool on files in the same way you can use it on
a repository.
 |
Click Quit in all BitKeeper windows.
|
Merging changes
The next part of the demo will illustrate how to merge conflicts.
BK/ProMerge can complete many complicated merges automatically, but
there will be times when there are merge
conflicts that need to be resolved by a human being.
The BitKeeper update process does not apply changes to your repository
until they have been merged.
Instead, the changes are pulled into a sparse repository called
the RESYNC repository.
When there are conflicts to merged, the bk pull command tells you
that as the last part of the output.
In the following section you will learn
-
what bk pull outputs when it can not automerge
-
how to run the resolver to resolve a conflict
-
what the file merge tool looks like and how to use it
-
how to check-in once you have performed a manual merge
Let's go see how that works.
Pulling and resolving a conflict
When you pull in a conflict that must be merged manually, BitKeeper
will automatically run the resolver and will prompt you to resolve the
conflicts. Let's pull in a merge conflict:
 |
cd ..
bk pull http://bkdemo.bkbits.net/bk_demo2
|
You should see:
 |
---------------------- Receiving the following csets --------------------------
1.124
----------------------------------------------------------------------------
ChangeSet: 1 deltas
e2fsck/recovery.c: 1 deltas
---------------------------------------------------------------------------
takepatch: saved entire patch in PENDING/2006-07-07.01
---------------------------------------------------------------------------
Applying 1 revisions to ChangeSet, renumbering, checking checksums
Applying 1 revisions to e2fsck/recovery.c
takepatch: 2 new revisions, 2 conflicts in 2 files
569 bytes uncompressed to 1363, 2.40X expansion
Running resolve to apply new work ...
Conflicts during automerge of e2fsck/recovery.c
resolve: 1 unresolved conflicts, starting manual resolve process for:
e2fsck/recovery.c
(content conflict) e2fsck/recovery.c>>
|
Because bk pull encountered merge conflicts, it
runs the resolver, which prompts you to resolve the conflicts.
(You can run the resolver manually with the bk resolve command.)
The resolver can handle a number of different conflict types, such
as content or rename conflicts.
Each conflict type has its own resolver "plugin" with a type
specific set of commands. In this example, you will be
handling a content conflict.
 |
Press "Enter" to see the command options.
Press "f" and "Enter" to run the 3 way file merge.
|
File merge
You should see a multi-pane graphical tool.
It has 6 panes:
-
The first "row" contains two small side by side windows.
These contain the checkin comments for the active diff.
-
The next row contains two larger side by side windows.
Each of these is a "stacked diff" window, showing the changes
from the common ancestor to the local (left window) or remote
(right window) versions of the file.
The active diff is the one with lines highlighted the width of the
window.
The darker highlighting with the leading "-" represents the lines
in the ancestor and the lighter highlighting with the leading "+"
represents the lines added by the local or remote version of the
file.
-
The merged file is shown at the bottom left.
-
The smaller lower right window contains instructions for the
active difference or conflict.
There is also a status bar which contains information about which
conflict you are on out of how many.
Each conflict that must be resolved by hand highlights the
status bar in red.
To select a line or block simply click in the upper left or upper
right boxes on the line or block that should be in the merged
file.
So, in the example, you're going to keep the changes you made and
complete the merge.
 |
Click in the upper right window on the line with "jREAD" highlighted in orange.
Press "u" to undo since you want the "Jread" changes.
Click in the upper left window on the line with "Jread" highlighted in orange.
Press the "]" key to go to the next conflict.
Click in the upper left window on the line with "Jread" highlighted in orange.
Press the "]" key.
Repeat until all conflicts have been resolved.
Type "s" to save.
|
Checkin
The file merge tool should have dropped you back into the resolver
interface.
If you are sure that you want to keep the merged changes you are
ready to commit the merge:
 |
Type "C".
|
If there were more files with conflicts, the resolver would prompt
you with the next conflict.
Since this is the only conflict, the resolver then brings up
citool to allow you a chance to comment the merge changes.
 |
Type in comments for all files.
Click Commit twice.
|
Update the parent
What you have done so far is to make local changes and merge in
changes from a different repository.
You have not yet updated the parent with your changes; they are only
in your repository.
In this section you will learn
-
how to use bk changes to see if there are local only or remote only changes
-
how to use bk push to update another repository with your changes
You can see if there are changes in the parent (or remote) repository that
aren't in your repository by running
 |
bk changes -R
|
You shouldn't have seen any changes.
You can see if there are changes in your local repository that aren't in
the parent by running
 |
bk changes -L
|
To update the parent repository, you need to do what is known as
pushing,
i.e., you push your changes to the parent repository.
To see where changes will go, run the bk parent command and then push:
 |
bk parent
bk push
|
After you push, the parent and your local repository are exactly the same.
If you pull or push, nothing should be transferred. Let's see what happens
when you try a bk pull:
 |
bk pull
|
You should not have received any updates.
You have now updated a repository with the changes that you made.
Finis
Congratulations! You have successfully run through some of the
basic and some of the more complex BitKeeper operations.
You've seen how to get views of the repository and its files via
the command line and via the graphical tools.
You have made modifications to a file, added new files,
checked in those files, and created a changeset.
And finally, you've run through a merge with conflicts that needed
to be resolved by hand.
You might want to delete the BK directory you made along with all
the demo repositories.
For more information about BitKeeper commands, try one of the following:
 |
bk helptool
bk help topic
bk help -k keyword
|
If you need further assistance, you can find it at
support@bitmover.com.
A next step in learning about BitKeeper is to try it on your own data. If
you would like to talk to a representative about doing a conversion
of your current tool's data, please send mail to
sales@bitmover.com.
Thank you for trying BitKeeper and we hope you liked your tour.
Company
BitMover is a privately held company incorporated in 1998 in the
state of California.
We are headquartered in Silicon Valley and maintain distributed
development groups in the United States, Canada, and Germany.
Our mission is to deliver the infrastructure required for
software, hardware, web, and other computer based development.
BitMover's dedicated engineering team has been working on our
flagship product,
BitKeeper,
since mid 1997.
Because we make tools which excel in today's distributed
development environments, we use our own products for our own
development and have been successfully doing so since 1998.
BitMover is profitable and is experiencing dynamic growth.
The majority of our sales are generated from the referrals of
satisfied BitMover customers.
What we do
We develop tools used for software, hardware and web development.
Our initial focus has been on a scalable source management tool
called BitKeeper.
We have invested heavily in the development of BitKeeper and are
now leveraging that investment by using the software as a basis
for new applications, such as bug tracking, sales tracking,
invoice tracking, project tracking, project management, project
hosting, etc.
Our roadmap has us developing and deploying these applications as
well as grouping them together to form what we call a virtual
developer ASP.
BitKeeper lets you take your source with you.
Our ASP will let you take your source, bug database, to do list,
mailing list, and any other required data with you.
The ASP model as it stands today has one fatal flaw: some company
you may or may not trust holds your data.
The BitKeeper ASP is a distributed, replicated, suite of databases
holding source, bug tracking, mailing lists, and everything you
need for your development projects.
The BitMover difference
BitMover is a unique company.
We provide a strong focus on engineering excellence with an
equally strong focus on our customers.
We have a solid, old-fashioned work ethic and a dedication to
quality which shows in our products and throughout our development
process.
If you report a problem to us, our commitment is to not only fix
it, but to develop a regression test that ensures you will never
see the same problem again.
We have developed proprietary clustering technology which allows
us to test our software on more than 30 different platforms before
you see it.
No matter how well we are doing, we know we can always do better.
We are constantly updating our processes in order to create more
useful and higher quality products to better serve your needs.
BitMover is an innovative company.
While other high-tech companies have taken the more common route
of using venture capital to fund quick growth for a quick return,
BitMover has been quietly building a strong foundation for long
term stability and sustainable growth.
Our business model is quite unusual and we view it as part of our
competitive advantage.
BitMover emphasizes quality and support.
We have been successful by providing excellent support to our
customers.
We don't sell our product unless we know we can support it.
Our philosophy is to build quality into our products.
We do not ship software that we know is broken.
All companies say these things, but in our case there is greater
pressure to make good on these promises.
Our products are infrastructure products, we know that if they
stop working so do you.
Hence our commitment to testing and a higher standard of
engineering.
BitMover hires the best people possible.
|