Release Notes

All platforms - Plastic, Gluon, Server, command line: Now the socket connect has a default timeout of 3 seconds, to avoid waiting forever on unreachable servers.

Timeouts are good to avoid waiting forever when you have network issues.

Now, if you try to reach an unreachable server that has a valid address, instead of waiting for 20 seconds (on Windows) it will throw an error in 3 secs:

> cm repo list 192.168.221.218:8084
Error: Can't connect to [192.168.221.218:8084] after 3000 ms. To increase the timeout set SocketConnectTimeoutMillisec in client.conf. Configure server.conf if the timeout happens during push/pull

== How to configure ==

Default is 3 seconds, but you can configure it in several ways.

For plasticprotocol (the default) just edit client.conf and/or server.conf (only if you have timeouts during push/pull) and add a new integer value with the following key:

SocketConnectTimeoutMillisec

The value is in milliseconds. If you set it to 0, it will be an infinite timeout.

In case you are using remoting, edit your remoting.conf file (valid for client and server) and add timeoutMilliseconds="4000" as follows:

channel type="PlasticPipe.Remoting.Tcp.PlasticTcpChannel, plasticpipe" name="normal" timeoutMilliseconds="4000"

All platforms - Server and all clients: Improved DNS name resolution during socket creation.

We've been working on introducing timeouts during socket connect. After doing that, we detected some issues during internal testing, where some connections timed out when they didn't before.

This was because the BeginConnect we use to do the async is internally doing some wrong stuff with name to IP resolution. Framework code that sometimes doesn't work as expected. Anyway, we introduced some fixes so we now avoid unneeded translations when the name is already an IP, and we also cache resolutions (not needed normally, but when the underlying network has some glitches, and we saw it with VMWares we use, it can happen).

Windows - Gluon: Incoming changes: the notification bar for the new 'Incoming changes' view is now available.

When you are working in a single branch with other people, it is common to find they have checked in new changes.

When this happens, Gluon will notify you on the top-right area of the window.

* Scenario 1: You have no pending changes and new changes from other users appear. Gluon will show you a green notification in order to allow you to see the changes in the Incoming Changes view, and update to them.

* Scenario 2: You have pending changes. New changes from other users appear, but they don't affect any of the files you have changed. Gluon again will show you the green notification for the same purpose.

* Scenario 3: You have pending changes. New changes from other users appear, and there are changes in files that you have also changed. In this case you need to merge these changes. Gluon will show you a red notification in order to allow you to see the conflicts in the Incoming Changes view, and resolve them.

This is how the Scenarios 1 and 2 look like:

And this is how the Scenario 3 looks like:

You can see it working here:

This feature is experimental. You need to manually activate it by adding the following line to the client.conf configuration file.

On Windows, it is at %LocalAppData%/plastic4 folder:

<EnableGluonIncomingChanges>yes</EnableGluonIncomingChanges>

Windows - Plastic: Workspace Explorer navigation was slow because every key hit triggered a network call.

Each time you selected a file in the Workspace Explorer, with the mouse or the keys, it wrongly triggered a network call to retrieve the global config and find external actions to add to the context menu.

It happened for branches, labels and changesets too.

We fixed it and now the external tools are only loaded when you switch workspaces, so navigation with keys is smooth again.

All platforms - Command line client is now able to do Incoming Changes both with cm update and cm checkin.

== How it looks like during update ==

> cm update .
Processing directory conflicts
Processing directory operations
Merging file 1 of 1: README.txt

== What if there is a directory conflict ==

> cm update .    
Going to resolve the following conflict:
Divergent move conflict:
  Source: Moved from /ConsoleApplication to /ConsoleApp                                                                                                                               
  Destination: Moved from /ConsoleApplication to /ConsApp                                                                                                         
Please choose a resolution for this conflict. Which operation do you want to keep?:                                                                                                         
  0. Skip  1. Destination  2. Source  
2
Processing directory conflicts
Processing directory operations
Merging file 1 of 2: README.txt
Merging file 2 of 2: ConsoleApp\AssemblyInfo.cs

== During cm ci --update ==

> cm ci -c "go in" --update                                                                                                                     
The selected items are about to be checked in. Please wait...                                                                                                                      
/ Validating checkin data                                                                                                                                                           
Processing directory conflicts                                                                                                                                                      
Processing directory operations
Merging file 1 of 1: README.txt 
Validating checkin data
Uploading file data
Confirming checkin operation
Modified README.txt
Modified ConsoleApp\AssemblyInfo.cs
Created changeset cs:1150@br:/main@quake@localhost:6060 (mount:'/')

Remember, the Incoming Changes is an experimental feature. It allows you to get the latest changes from the server, rebasing your pending changes on the process. You can see how it works at: Single branch workflow improvements: announcing Incoming Changes

To enable this feature, simply add the following line to your client.conf configuration file:

<EnableIncomingChanges>yes</EnableIncomingChanges>