Release Notes

Public

Release 6.0.16.1744

Nov 07 2017
New

No-data replica is now ready! Grab metadata but skip data to have light but fully workable local repos.

You can use the --nodata flag in the cm replicate command to pull metadata to your repo while skipping the actual data.

== What is replica no-data all about ==

The motivation is clear: huge local repos (dozens of GB) are painful because you end up with tons of data you won't be using most of the time. Why not simply replicate the metadata so you can effectively branch and checkin, while getting the actual data from the original server on demand?

== An example is worth a thousand words ==

You just create a clean local repo, then replicate a single branch from the remote server, without data. You can branch from it, checkin, do whatever, and freely push changes back correctly, but your local repo will be tiny.

cm mkrep game-of-cores@localhost:8087

cm replicate main@game-of-cores@volantis:8087 game-of-cores@localhost:8087 --nodata.

cm mkwk wk-dev .

cm mkbr main/got-1023

cm switch main/got-1023

Since localhost:8087 doesn't have any data, files will be downloaded from the original server volantis:8087 during update.

Your working copy will be fully operational, and your local repo will be tiny.

By the way, as soon as you checkin locally, new data will be entered in your local repo, no problem about that.

Finally, you will be able to push your newly created branch back to volantis:8087

cm replicate main/got-1023@game-of-cores game-of-cores@volantis:8087 --push

== What is the vision ==

Our vision here is: working distributed is the way to go but since we are online most of the time, why not take advantage of it?

All checkins go super-fast locally (waiting to checkin is a productivity killer), but we are online, so let's grab actual data from the central.

== What if I really need to go offline ==

First, if you updated your workspace while connected... well, you already have the data locally, so chances are we got you covered.

Alternatively, you can always continue using regular replica, which is fine.

Finally, there is a way to simply "hydrate" certain changesets (or branches) while the rest of the repo remains data-less :-P

== Hydrate - nodata perfect companion ==

Nodata replication has a perfect companion: the cm replicate hydrate command, which lets you download data for a certain changeset to your local repo from a given specified source.

It works as follows:

cm replicate hydrate cs:1724@myrepo quake@central:8087

And you can also hydrate a branch if you want to (which will actually hydrate all its changesets):

cm replicate hydrate main@myrepo quake@central:8087

Bug

The revert operation was not locking (getting the exclusive checkout) the reverted files. Now the lock is done as expected.

Bug

The cloaked exception rules were not working inside a cloaked xlink. See an example:

Cloaked rules:

**

!*.jpg

Tree:

/

/src

/src/foo.c

/theme (xlink)

/theme/app.ico

/theme/logo.jpg

Before the fix, all the workspace content was cloaked and no content was downloaded. The second line ('*.jpg') didn't affect the xlinked contents.

Now, that rule is properly applied to the whole tree and only these items will be downloaded:

/

/theme

/theme/logo.jpg

REMARKS: this fix requires both server and client to be updated.

Bug

When configuring ignored/cloaked rules, the workspace-relative paths are still allowed by prepending the text "$workspace". But it was not properly working for exception rules.

eg:

$workspace/myproject/*

!$workspace/myproject/code.cs

Public

Release 6.0.16.1735

Nov 01 2017
Bug

Windows GUI: In the pending changes view, the diff viewer was not refreshed after checking in or undoing changes. Now it's fixed.

Bug

Server stopped listening to the input of a given network connection after discarding an unsupported method in PlasticProto only if the first request was bigger than 80KB.

It was all an issue with buffered reading being handled incorrectly under quite rare circumstances.

Bug

Modified replica code for push in the server so that fetching a huge amount of metadata doesn't end up with a cancelled remote transaction due to inactivity. The issue was that we were creating a remote transaction (plastic type of transactions, not database) on the remote server at the very beginning, then if the fetch took too long (like more than 30 minutes), the remote transaction was aborted and the replica failed after finishing the fetch phase on the local server and when connecting the remote to transfer the metadata.

Bug

Server was mistakenly closing sockets when the method call took more than 60 secs (extremely unusual but doable). This was because we entered a protection mechanism to prevent clients to stay connected forever, but we didn't consider that the socket is being monitored for closing (so we do a read) before the method finishes. Fixed now.

Public

Release 6.0.16.1723

Oct 27 2017
Bug

Windows installer: If the server was configured using auto-renewal token license, the upgrade could override port and authentication working mode. Fixed.

Bug

Windows GUI: In the pending changes view, the diff viewer was not refreshed after checking in or undoing changes. Now it's fixed.

Public

Release 6.0.16.1718

Oct 26 2017
New

Gluon: Allow to resize checkin comments textbox. Also support Ctrl+A to select all the text in the textbox.

Bug

Mac/GTK: Nested dynamic views weren't disposed correctly if their parent dynamic view was closed. Fixed.

Bug

Fixed a null during parallel update introduced in 6.0.16.1675

Public

Release 6.0.16.1706

Oct 20 2017
New

GTK: A new 'Browse repository on this changeset' context menu option was added to the Changesets View and the Branch Explorer changeset selection. It will show a dynamic view to navigate the repository contents in the selected changeset.

New

Mac: A new 'Browse repository on this changeset' context menu option was added to the Changesets View and the Branch Explorer changeset selection. It will show a dynamic view to navigate the repository contents in the selected changeset.

New

GTK: The new 'Browse repository on this changeset' view has been completed adding a context menu with the following options:

* Open

* Open with

* Save as

* Diff with previous revision

* View history

New

Mac: The new 'Browse repository on this changeset' view has been completed adding a context menu with the following options:

* Open

* Open with

* Save as

* Diff with previous revision

* View history

Bug

CLI: the unco command wrongly performed a full unco if it was called with a wildcard argument (e.g 'cm unco src\f*') that didn't match any contents on disk.

The wildcard arguments expand to generate a set of disk paths matched by the argument. When there are no matches, the "unco" command is called with an empty set, resulting in a full undo checkout operation (the same way as executing "cm unco" without arguments).

We fixed the wildcard argument behavior to avoid a full "undo checkout" operation if no disk paths are matched.

Bug

Release 1699 was unable to migrate data when Plastic Server ran as a Windows Service. All because a temporary db.conf file created in the wrong location (full path not specified ended up creating the file in an unexpected place running as SYSTEM account).

Internal and public releases

The Plastic SCM development team works in short iterations delivering frequent releases.Our goal is to have at least one new release every week, with new functionalities, bug fixes and performance tweaks.

Every 'weekly' release is not published to our customers, but we like to detail each of them in the release notes so users can easily follow what we achieved on every short iteration.

The releases marked with the word "public" are the ones we do publish on the website. The ones marked as "internal" are the releases we create in-house to keep the project moving week after week.

Version numbering

Starting in Plastic SCM 4.0 the version numbering schema has been modified:

  • major.minor.compatibility.buildnumber

  • Sample: 5.0.44.511 means:
    • 5 -> major release number
    • 0 -> minor release number
    • 44 -> compatibility -> all clients and servers with "44" in the compat number are compatible, even if the build number changes
    • 511 -> internal build number