Jump to content

Re-use of existing workspace after replicating to local server


deanaug

Recommended Posts

Hi,

A couple of our guys are taking our software "on the road" to integrate with another developer, so I explained how we could replicate their branches from our network server to the local server on the machine they are taking, then do remote checkouts/ins on the local server, then replicate those changes back to the network server upon their return. Since they already had a workspace set up on the machine (from the network server), I figured they could "re-use" that workspace after the switch to running standalone with the local server. Our main motivation there was the presence of private Eclipse etc. files scattered around the code directories, and avoiding having to reconfigure VxWorks Workbench to run in a different directory. We had trouble setting up with the workspace though. Here is the sequence we followed, and what went good/bad:

1. Code was on two branches, /main and /main/developer. We created a replication package for each branch from the network server, and imported those packages into the local server. Learned the hard way you have to import the parent branch first (in this case /main), so Plastic knows how to base the child branch (/main/developer). :P So far so good.

2. With the local server now populated with all the right items, we then disconnected the machine from the network and reconfigured the client to point to the local server. We started the client and created a new workspace, specifying the path already fully populated from its use with the network server. So far things seemed OK.

3. Subsequently trying to access that workspace from the client did not go so well. At first all we got was error messages telling us the client could not access the network server (which was odd because we had reconfigured to point to the local server). After some poking around, we noticed the plastic.wktree file in the .plastic directory still had the network server name/port, so we wound up editing that file by hand to put in the local server name/port. Once we did that, the client was able to bring up Items, Branch Explorer, etc. for the workspace, so things seemed to be looking up.

4. Once we had access via the workspace, we tried to do an Update to make sure things were synced up and happy with the local server. We had lots of problems here, Plastic repeatedly kept stopping the update and reporting it could not update random files (forget the exact error message, think it was file permissions??). After deleting the offending files/directories and retrying the Update numerous times, we finally gave up trying this whole approach. After reconfiguring and resyncing everything back to the network server, the current plan is to "brute force" any changes locally on the machine, then sneaker net them back into Plastic on the network server later.

So, my question is, should this have worked OK? As I said, the replication part went beautifully, but trying to use the pre-existing workspace definitely did not. I'm hoping we just missed some steps or did something wrong in the description above, since we will need to do this from time to time, and we picked Plastic over other CM tools specifically because it does handle distributed operation so well. :)

BTW we are using Plastic 3.0.187.26.

Any help would be greatly appreciated.

Thanks!!!

Dean

Link to comment
Share on other sites

Hello Dean!

Ok

After some poking around, we noticed the plastic.wktree file in the .plastic directory still had the network server name/port, so we wound up editing that file by hand...

By hand!!! You are a hacker! hehehehe but nice try!!

Ok, let's see, this is the right process.

1) Configure the client to connect to your local server.

2) Open the GUI -> It must fail since the wks is configured to use the old connection, it's fine, accept the error and close the GUI.

3) Open a command line tool, change your directory to your workspace path and issue "del .plastic\plastic.wktree" and then "cm update ." (Notice the last dot "." in the cm command, it's not a typo)

This last update operation is not going to download anything, it's only going to re-build the wktree file.

Obviously the replicated repository must have the same name as the central one, if not you have to change the repository name inside the "plastic.selector" file inside the ".plastic" directory.

Tell me if it works for you!

Link to comment
Share on other sites

Thanks for the response Manu!!!

Yes in desperation we did resort to a bit of hacking. ;)

Yeah we made sure the replicated local repo had the same name as the central one, so the existing selector should work fine.

Unfortunately the lab machine we were trying this on is now off-site, but when I get a chance I will try the same thing on my machine and post the result.

Thanks again!!!!!!!!!!!!!!!!!!!!!!!!!!

Dean

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...