Who we are

We are the developers of Plastic SCM, a full version control stack (not a Git variant). We work on the strongest branching and merging you can find, and a core that doesn't cringe with huge binaries and repos. We also develop the GUIs, mergetools and everything needed to give you the full version control stack.

If you want to give it a try, download it from here.

We also code SemanticMerge, and the gmaster Git client.

Cloning repositories to (and from) a package

Thursday, June 06, 2019 Sergio L. 0 Comments

If you pay attention to the release notes, you probably know that Plastic's command line client now has a clone command. If you are used to other version control tools, then using it will be as easy as falling off a log. If not, let me tell you what the cm clone command does—it creates an exact copy of a remote repository in your Plastic SCM server.

You just need to type in the remote repository specification, and the cm will take care of creating a local repository of the same name (if it doesn't exist yet) and replicating all the content from one to the other.

The syntax of the cm clone command is as follows:

> cm clone <src_rep>@<src_rep_server> [dst_rep_server]
cm clone has some more advanced options that you can learn about by calling cm help clone.

For example:

> cm clone codice@central.home:9095 codice@co-located.home:8084

If you don't specify the destination server, the clone command will use your default server.

I know what you're thinking. What if I don't have a direct Internet connection between source and destination? No problem. You can clone to a package! Let me show you how:

Starting in version, you can specify the path of a package as the destination of the clone:

> cm clone <src_rep>@<src_rep_server> [--package=<pkg_path>]

For example:

> cm clone codice@central.home:9095 --package=codice.plasticpackage

Once you create the clone package, you can use the cm pull command to introduce its data into the destination repository. It is recommended that you choose an empty repository as the destination, because of the potential for branch name collisions. (Collisions are resolved by renaming the one branch, to avoid losing data).

> cm pull --package=codice.plasticpackage codice@central.singapur.com:9095
cm clone can't clone from a Cloud server to a package due to limitations of the platform.

You can see the complete cycle in this image:

Easy, right? If, instead of the whole repository, you only want to replicate a single branch, you can use the new push and pull commands. (These replace replicate). At first it might be a little difficult to understand when to use each one: as a rule of thumb, remember this:

  • In both these commands, first comes the source of the data, then the destination.
  • The source can be a branch or a package. The destination can be a repository or a package.
  • You push when you want to export your work to a remote location.
  • You pull when you want to import somebody else's work from a remote location.
> cm push br:/main/mybranch@myrepo@myserver:8087 your-repo@yourserver:9095
> cm pull br:/main/yourbranch@your-repo@yourserver:9095 myrepo@myserver:8087

Remembering these semantics, it is clear when to use push or pull when the source or the destination is now a package:

  • You push to a package when you want to export your work to a file.
  • You pull from a package when you want to import somebody else's work from a file.
> cm push br:/main/mybranch@myrepo@myserver:8087 --package=mywork.pkg
> cm pull --package=yourwork.pkg myrepo@myserver:8087

The --package argument can appear anywhere in the command. Here we type it before the destination while pulling to keep the <source> <destination> order, but it's not mandatory. You don't have to remember that!

I hope you find these new commands as useful as I do. The clone command is something many of you have wanted for a long time, and push and pull simplify the deprecated replicate command without losing functionality.

As always, if you have any doubts or problems, or any ideas, please feel free to comment below, or contact us on Twitter @plasticscm. We'll get back to you as soon as possible!

Sergio Luis
After an intense internship at Codice during spring and part of summer 2015, I joined the ranks of Plastic SCM as junior developer.
I already contributed code to the Plastic REST API, the HAL Slack bot that controls our CI system, migrated our internal main server to "new" hardware, coded an Android repo browser and hacked wifi-direct for the upcoming Plastic version.
You can reach me at @_sluis_.

0 comentarios: