Implement Lanes and Snaps features

[davidfirst]

See more details about these two features here: Lanes. Snaps.
Note that for now, these features are disabled by a feature toggle "lanes". Our recommendation is not to use it yet.

The following describes the final implementation, which differs from the specification above.

Synopsis

• create a snap: bit snap (synopsis similar to the bit tag).
• create a new lane: bit switch <name> --create
• list lanes: bit lane.
• switch between lanes: bit switch <name>
• merge lanes: bit merge --lane.
• show lane details: bit lane <name>
• track local lane to a remote lane: bit switch --as
• rename a lane bit switch --rename
• remove a lane bit remove --lane.
• fetch lane objects (without the components): bit fetch --lanes.
• import a lane: bit switch <name> --remote.
• export a lane: bit export <name> --lanes.
• export current lane: bit export.
• (internal) cat lane object: bit cat-lane <name>.

Remaining tasks

• Remove components from a remote lane.
• Bit import with no args. When bitmap has a remote lane, should import the lane.
• Tag dependencies to include them in a lane.
• Test bit-fetch components
• Rename lanes.
• "Bit diff" between lanes
• Fix performance issue. Now it fetches all parents every time. It doesn't make sense.
• Fix performance issue. Now it traverses all parents to see if a hash in there.

Important points

Performance consideration

Currently, if it imports with no-deps, it doesn't ask for parents, if it imports with deps it imports with all parents. It is originated from src/api/scope/lib/fetch.ts: const collectParents = !noDependencies;. We need to make a decision here.

Model changes

• Version.parents. This is added only if the lanes feature is enabled. (it doesn't change the hash).
• Component.head This is added only if the lanes feature is enabled. (it doesn't change the hash).

Hash

• Snap's hash is generated by a UUID and then converted into sha1. sha1(v4()).
• Lane's hash is generated by a UUID and then converted into sha1. sha1(v4()).
• Tag's hash stays the same. Generated by the Version.id().

Lane Data

Lane data, for the most cases is a map of component-id:snap-head, in other words, it saves per component the head snap. There are 3 different places where we store such data for different purposes.

• lane-object "Lane" is saved in the scope .bit/objects (.bit can be .git/bit locally), it has a unique hash and contains a map of components and their heads. This object exists on both local and remote scopes. Its main purpose is to sync lane-data between scopes. See Lane class (in scope/model) for the implementation details.
• workspace-lane (component and their heads) is saved in .bit/workspace/lanes/lane-name. Remote scopes don't have this data. Its main purpose is to store data that exists only locally and does not exist on the remote. See WorkspaceLane class for the implementation details.
• remote-lane (component and their heads) is saved in .bit/refs/remote/remote-name/lane-name. These refs files are saved in both, local and remote scopes. Its main purpose is to keep track where the remote-heads are per lane. See RemoteLanes class for the implementation details.

More places that stores lanes related data:

• the currently checked out lane is saved in the scope.json file. (e.g. { lanes: { current: "lane-a", tracking: "remote/lane-a" } }).
• When switching to a remote lane, the .bitmap is updated as well with the remote-name, so then, when cloning the project, it's possible to fetch the remote lane data.

Summary of when/what lanes data is saved per command:

• bit switch --create: creates a new lane-object.
• bit snap: adds an entry to the lane-object and to the workspace-lane.
• bit export: 1) deletes all records from workspace-lane (as they're in sync with the remote). 2) pushes the lane-object to the remote. On the remote, the lane-object is created or updated/merged.
• bit import/fetch: 1) creates/updates lane-object in the scope. 2) creates/updates remote-lane. the remote-lane is updated also for master.

Merge during import

• When the remote is ahead, it's easy, just update the head to the remote-head.
• When the local and remote have diverged, it's more complex. We need to create a snap-merge that has two parents, one point to the local head and one point to the remote head.
• On bit import --objects (or bit fetch) we don't merge. The remote head is saved in the .bit/refs/remote dir. Then, bit status shows that these components are merge-pending.
• On bit import <id> we do the merge.
• in case the merge wasn't done and the user is trying to export, the remote blocks is as it finds out that its head doesn't exist on the incoming component.
• in case the snap-merge failed due to a conflict, it saves the conflict and heads data into .bit/unmerged.json file.

Useful APIs

• bit-map getAllIdsAvailableOnLane() filters the currently checked out lane.