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.

Plastic now checkouts before merge

Wednesday, October 30, 2019 Pablo Santos 0 Comments

We introduced a huge change in (2019-10-29). From now on, your local changes will convert into controlled changes (checkout) before calculating a merge.

What changes

Pending changes are now converted into checkouts (controlled changes) before calculating a merge.

We decided to do this to improve usability.

We are announcing this with emphasis because we know many long-term users might be confused at first.

Why we decided to apply local changes before calculating a merge

Simply put, to avoid users encountering errors caused by corner cases.

Let me explain it with an example. Suppose you have foo.c modified in your workspace and then you merge from main/task001 where foo.c was also modified.

foo.c is just a "local change". It is modified locally, but not "controlled". It shows up as follows:

It is not "under Plastic control" yet.

Well, the merge won't consider foo.c as a conflict in the preview (which is confusing) because it only considers "controlled changes" a.k.a. checkouts.

But, if you checkout foo.c then the merge preview shows the conflict.

Even if foo.c is not checked out, the merge is correct because foo.c is "promoted to checkout" during the merge.

Let's see a different example now:

  • You move art/ into game-art/ locally
  • There are changes inside art/ in main/task001.
  • The merge won't consider your local changes and it will end up causing trouble.

We fixed all this by simply "applying changes" before calculating the merge. This means that any local "changed" will be converted into "checkout" and also that local moves, local deletes, will be put under control too (checkout for short).

It is an important change to ensure consistency and avoid corner cases.

What are checkouts exactly

Plastic supports two ways of working:

  • You can directly modify foo.c, then go to Pending Changes and checkin.

  • Or you can checkout foo.c first, then modify, then checkin.

Checkouts are just a way to say Plastic "hey, I modified this file", or "hey, I moved this file this way", so it doesn't have to "guess" what happened.

Plastic is very good at guessing what you did by looking into the workspace and detecting changes, but it is even faster if it doesn't have to guess because "it knows" a change or a move happened.

Checkouts are not locks. You can checkout foo.c and it won't be locked at all. In fact, checkouts are stored locally and don't impose any performance issues at all.

Checkouts only lock files (a.k.a. exclusive checkouts) when the files are configured to be locked. This way, you can say all .png files must be locked on checkout, and when you checkout game.png it will be locked. Locks are stored on the server, although the performance impact is minimal.

Checkouts are like adding to Git Index

A note for former Git users. Plastic checkouts are like adding something to the Git index. As easy as that, just telling something is really controlled now.

Checkouts are like Perforce p4 edit but faster

And a note for former Perforce users. Plastic checkouts are similar to p4 edit but without the performance impact.

How it works

When you launch a merge, before actually calculating the merge in the server, your local changes will convert to "controlled changes" a.k.a. checkouts.

Pablo Santos
I'm the CTO and Founder at Códice.
I've been leading Plastic SCM since 2005. My passion is helping teams work better through version control.
I had the opportunity to see teams from many different industries at work while I helped them improving their version control practices.
I really enjoy teaching (I've been a University professor for 6+ years) and sharing my experience in talks and articles.
And I love simple code. You can reach me at @psluaces.

0 comentarios: