Plastic now checkouts before merge
We introduced a huge change in 8.0.16.3673 (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.
0 comentarios: