Starting Plastic with new repository server

[Soho]

Last time I used the Plastic SCM GUI, it was configured to use a repository on a particular server.

Now this server has crashed, but good thing Plastic is a DVCS, so I had a replicated repository on another machine.

To switch repository I used the client configuration wizards, but the GUI still insist on connecting to the old server.

Obviously the GUI doesn't support a repository being down (it would be nice if it did), so I assume I would have to use some command line wizardry, to switch workspace repository.

How would I do that?

Is there a way to do this in the GUI I have overlooked? (I cannot do anything, since it just keeps popping up a message about not being able to connect to the crashed server).

[miller]

hi Soho, server crash!

OK, indeed, you need CLI, what is happening here is that your old workspaces are pointing to the old server, open a cmd.exe and do the following steps.

If you know you had checked out items, save them to another place.

close your GUI

cm lwk (will list your workspaces)

cd to each workspace and do: cm update . [That is a DOT after update]

thats all, starting your GUI will have your workspaces pointing to the new server.

Miller

[Soho]

Hi,

I finally figured out the "cm update ." thing my self, though it was tough since one of the work spaces referred to a branch that only existed in the crashed repository, so updating also required tingling with the selector.

Also, I found it hard to find good documentation about this.

A thing I was pleasantly surprised with however, was how easy it was to import the repository from the crashed server. I just copied the repository file to another server and restarted the plastic service, and voila, the crashed repository was back in business. That part is really well done in Plastic. I didn't like the GUI not responding when a repository is offline. Instead of repeating the message about the server being down, it would be nice if it provided options for changing the repository server and update the work spaces. This should be a feature that makes a DVCS shine.

[pablo]

Hi Soho,

Thanks for your suggestions. Believe me when I say we'll do our best to put them into production.

Yes, moving repos is easy, so easy we probably take it for granted, which is a mistake. Here is where our beloved community could help us a little with a short but straight to the point blog post explaining how things get done !

Thanks,

pablo

[Soho]

It is nice with all the quick responses in the Forum from you, the developers.

Regarding changing repository away from a downed served, I think you could save a lot of frustration from many users by making it more seamless.

To solve the problem I messed around with all the Plastic configs and tried a lot of workspace / repository command line actions. What finally solved the problem, the rather trivial "cm update", was not intuitive for me. It is probably quite intuitive for at Plastic developer who knows in details what an update action does.

I appreciate what you do to make Plastic an intuitive tool, because the very nature of a DVCS is comples. Plastic has a high degree of freedom and lot of concepts that takes some time to grasp the differences between: Branches, changesets, repositories, replicated hosts, workspaces, files and folders, shelves. In most developer teams I would say that only a few people, if any, intuitively understand the relations between all these concepts.

In this case I had the model in my head, that I had a work space mapping between a file folder and a specific branch on a specific repository on a specific server. In that mental model, intuitively, all I had to do was to change the repository mapping from one server to another, but the selector did not specify a server mapping, only a repository and branch mapping, which kind of broke my mental model and left me confused, when Plastic kept insisting on connecting to the old server even after I reconfigured it to a new one.

[pablo]

Hi Soho,

Regarding the "selector" pointing to a repo. Look at mine:

repository "doc@diana.codicefactory.com:9092"

path "/"

branch "/main"

checkout "/main"

Another "trick" here (I guess) is that you can specify a server together with the "repo spec".

As you know, the "repo name" in the spec comes from:

- your default server (workspaceserver entry in client.conf)

- the first match if you have multiple servers defined in plastic.servers

And now, a "tale": in the beginning (<3.0) we had separated workspace and repository servers (it was optional, but architecturally it was there all the time). It was very flexible since you were able to separate the two, and even better, repos could have "aliases" so you could change the alias to a repo, let's say myrep pointing at "myrep@oldserver:8084", and then make it point to a different location (a repo that is moved from one server to another) transparently to clients...

It was a cool feature (inspired on ClearCase's view/vob servers) but we got rid of it... I was the killer of the feature so you can blame me... (I was the creator too so...), and the reason was... speed!! In load testing (you know we test with a beautiful 100-nodes cluster) we were able to crunch competitors (SVN, P4, others... ) as soon as we made workspaces fully local (server doesn't know about them since 3.0). So... we did it!

pablo

[Soho]

repository "doc@diana.codicefactory.com:9092"

path "/"

branch "/main"

checkout "/main"

Where would I find the syntax documentation for the selectors?