Dead Plastic server cause multiple problems but updating xlinks impossible?

[wnicholls]

Scenario:

 

I had an old server  - name "orison.csl" which has died  (not 100%, but bringing it back will be several valuable hours' work).  (I did attempt to get off this server onto a reliable VM before it died completely so some of my experience here is much more proactive than it sounds).

 

I have plastic 5.0.43  (latest as today)  installed on the new server "plastic.csl" (this is a DNS alias so I hopefully won't have to deal with this again).  Both are/were using SQL Server backend.

 

I've managed to get the old repositories (SQL database restored) on the new server and even managed to switch the selectors on the workspaces. It was harder than it should have been, but it is running. (I think the 5.0.43 server config tools have a bug around user/password mode but I'm not going into that now).  In one case I simply deleted and readded the workspace in the GUI, leaving the files in place.

 

There's a lot of grief and trying different things I'm not going to write in this post. I'll try and call out only the relevant stuff but please keep in mind this is the end of a small journey.

 

So I have a couple of beefs and one almost-insurmoutable problem. nearly all come back to the same basic point - the old server is dead and the Plastic client tools deal with this very very badly.

 

1) The Plastic GUI  at least cannot handle talking to more than one server if the server versions differ. The old server was 5.0.42, the new one and my upgraded client 5.0.43. The client tools basically throws a wobbly if the client and server versions do not match even in minor patch version.

 

2) The workspace "Set Selector..." menu item couldn't switch workspaces because there were pending changes. It suggested I resolve them first however I was unable to access the old server

 - even if I could (when I had the server running) it complained about client&server version not matching. Ergo, it appears to be impossible to switch a workspace from one server to another when the server versions are different.  Not a big deal for me but would be if there were more users.

 

3)  OK so I can manually edit the .plastic/plastic.selector file and point to the new server. BUT...  now I have a couple of xLinks that still point to the old server. These cannot be changed.

 

For example say I have an xLink called xyz, If I try this:

 

  cm xlink -e -w  xyz  /  cs:"44@xxyz@plastic.csl:8087"

 

then I get:

 

  Error: No channel found trying to connect to [orison.csl:8087 (unreachable)]

 

Too right it is unreachable!   And as above, even if I got it back (temporarily) it would be running Plastic 5.0.42 and the versions probably wouldn't mismatch.

 

I did try - desperate measures - editing my hosts file to point "orison" to the same IP address as the new server.  Then the xlink -e  worked  although it still left expansion rules that pointed to the old server (deleteable with cm xlink -dr)

 

Now I managed to check in  my changes - however when I remove the hosts entry, it is STILL referring to the old server. No sign that I can see in the workspace GUI or other tools that it should do so although a file search shows that .plastic/plastic.wktree contains the string "orison"/

 

But once again, deleting the workspace and recreating (pointing to the new server) works.

 

I know this is going to sound a little like a complaint, but beautiful and awesome Plastic SCM is in many ways, it is immature in this aspect.  In particular, I find the way each point release requires a full enterprise-wide update so every server and client has the same version.  At the moment I'm really just evaluating this: I have 4 repositories, one server, and two clients (who are both me: Windows and Linux) - but even this is annoying and dissuades me from upgrading.

 

The sad thing is that I doubt your client-server communictation protocol changed in the slightest between 5.0.42 and 5.0.43

 

(On the other hand there was a nice feature where the Plastic client GUI downloaded its own upgrade version, which in the single-server scenario would work quite well.)

 

But in summary, I have succeeded, although I could do with having my 3-hour voyage of discovery replaced by a few good knowledgebase articles.  It seems like moving a server instance from one box to another is not a way-out use case!

For the record I did try setting up replication between the old server and the new but this was an abysmal failure. I think the documentation could be improved here although fundamentally it seems like it SHOULD work.  From memory think my problem was that I wanted the entire change history migrated and replication didn't seem to handle that (being more oriented towards DVCS scenario rather than a backup/restore).   I might have got that going if the failing server didn't push the issue.

Thanks all

 

Walter

 

 

 

 

 

 

 

[calbzam]

Hi,

 

1) Plastic 5 is a pretty new release (LABS section) and we enforce to add new features and improvements although we frequently break compatibility.  With our official 4.1 version we try to keep retrocompatibilty and stability as much as possible. Anyway, updating process shouldn´t be a problem (only run the installer) in case you want to have the last Plastic 5 version.

 

In summary the third number in a release number indicates common types version and compatibility.

 

eg 5.0.42.482 is not compatible with 5.0.43.490

 

eg2. 4.1.10.493(October 2013) is compatible with 4.1.10.293 (June 2012)

 

I can confirm that Plastic 5 will be our officially supported version very soon, and when it happens we will enforce retrocompatibility as we do now in Plastic 4.1

 

2) Reusing the workspace when switching to a different server I agree is not a trivial process. We have some posts trying to deal with this situation:

http://www.plasticscm.net/index.php?/topic/1844-unable-to-change-repository-address-of-workspaces/?hl=workspace

 

3) We are working on some tasks that improve the behavior when a Xlinked repository is not found (or IP adress change).   Deleting the Xlinks and recreating them or creating a new workspace should fix the issue. But I agree we should polish process and we are working on it.

 

Regards,

Carlos