RepliKate getting stuck on cloud credenntials on linux (ubuntu) server.

[Lucas]

Hello,

I'm new to plasticscm and I'm trying to setup RepliKate on my ubuntu server but I'm having trouble with the command getting stuck waiting for my cloud credentials and I couldn't find how to work around this problem.

Here is what I've done so far:

1. Compiled RepliKate,copied the files to /opt/plasticscm5/replikate and set proper permissions:

2.Executed RepliKate using plastic's copy of mono:

3. The command gets stuck there and if i try running the last printed line, i get the following:

I'm assuming the same prompt happens during RepliKate execution but I cant find how to fix this.

Any suggestions?

Thanks =)

[manu]

Hi @Lucas,

Yes! I think if you do the following you will get rid of the credentials dialog.

1) Run the "clconfigureclient" tool.

2) Configure the setting to connect with your cloud client.

3) Move the "/home/<Your_user>/.plastic4/client.conf" file to "/opt/plasticscm5/client/

4) Verify you can run "cm lrep" with your regular user and with "sudo" as well.

If you can successfully run both "lrep" commands then I think the repliKate should work just fine.

[Lucas]

Hi @manu,

That didnt't work given client.conf only store the last configured credentials and i needed it to have my credentials for both my server and the cloud. But I tried your cm lrep test on my windows client and so i guessed these credentials should have been stored somewhere in my config files on the windows machine.

Looking around I realized that my windows client uses a profiles.conf file to store several credentials like this:

<?xml version="1.0"?>
<ServerProfileData xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <Profiles>
    <ServerProfile>
      <Name>gilp@cloud_LDAPWorkingMode</Name>
      <Server>gilp@cloud</Server>
      <WorkingMode>LDAPWorkingMode</WorkingMode>
      <SecurityConfig>::0:username:crypted_pass:</SecurityConfig>
    </ServerProfile>
    <ServerProfile>
      <Name>mylocalservername:8087_UPWorkingMode</Name>
      <Server>mylocalservername:8087</Server>
      <WorkingMode>UPWorkingMode</WorkingMode>
      <SecurityConfig>username:crypted_pass</SecurityConfig>
    </ServerProfile>
    <ServerProfile>
      <Name>localhost:8087_UPWorkingMode</Name>
      <Server>localhost:8087</Server>
      <WorkingMode>UPWorkingMode</WorkingMode>
      <SecurityConfig>username:crypted_pass</SecurityConfig>
    </ServerProfile>
  </Profiles>
</ServerProfileData>

Using "cm crypt" i was able to properly fill the SecurityConfig tag with my respective usernames and crypted passwords.

Now if I run replikate repo@mycloudorganization@cloud repo@localhost:8087 it works fine with the following output:

$ sudo /opt/plasticscm5/mono/bin/mono /opt/plasticscm5/replikate/RepliKate.exe areia-art@mycloudorg@cloud areia-art@localhost:8087 --onlyshowunsynced=false
Log at : /opt/plasticscm5/replikate/RepliKate.log.conf
/home/gilp$ cm find branch --format={name}#{id} --nototal on repository 'areia-art@mycloudorg@cloud'
Plastic SCM shell
/main#3
/main/dev#1000

Going to replicate the following branches:
br:/main Id 3
br:/main/dev Id 1000
/home/gilp$ cm replicate "br:/main@areia-art@mycloudorg@cloud" "rep:areia-art@localhost:8087"
OperationStartingFetch
OperationStartingFetch
OperationStartingFetch
OperationStartingFetch
OperationStartingFetch
CalculatingInitialChangeset
etchingFinished. 3 %
FetchingFinished. 3 %
FetchingFinished. 498 %
ataWritten
Items 0
Revs 0
ACLs 0
Changesets 0
Labels 0
Applied labels 0
Links 0
Applied links 0
Attributes 0
Applied attributes 0
Reviews 0
Review comments 0

/home/gilp$ cm replicate "br:/main/dev@areia-art@mycloudorg@cloud" "rep:areia-art@localhost:8087"
OperationStartingFetch
OperationStartingFetch
OperationStartingFetch
CalculatingInitialChangeset
CalculatingInitialChangeset
FetchingFinished. 7 %
FetchingFinished. 718 %
FetchingFinished. 718 %
DataWritten
Items 0
Revs 0
ACLs 0
Changesets 0
Labels 0
Applied labels 0
Links 0
Applied links 0
Attributes 0
Applied attributes 0
Reviews 0
Review comments 0

however, i want to replicate my local server on the cloud and if i try runnig replikate repo@localhost:8087 repo@mycloudorganization@cloud  I get the following output:
 

$ sudo /opt/plasticscm5/mono/bin/mono /opt/plasticscm5/replikate/RepliKate.exe areia-art@localhost:8087 areia-art@gilp@cloud --onlyshowunsynced=false
Log at : /opt/plasticscm5/replikate/RepliKate.log.conf
/home/gilp$ cm find branch --format={name}#{id} --nototal on repository 'areia-art@localhost:8087'
Plastic SCM shell
/main#4
/main/dev#38

Going to replicate the following branches:
br:/main Id 4
br:/main/dev Id 38
/home/gilp$ cm replicate "br:/main@areia-art@localhost:8087" "rep:areia-art@mycloudorg@cloud"
Error: No such host is known

Command cm replicate "br:/main@areia-art@localhost:8087" "rep:areia-art@mycloudorg@cloud" failed with error code 1
Error replicating branches: Replication didn't finished properly: Branch/main
at repliKate.Replicator.Replicate (System.Collections.IList branches, System.String src, System.String dst, System.String wkpath, System.Int32 initBranch) [0x00152] in <416cafce4578458aace2e15386b62b43>:0
at repliKate.RepliKate.DoReplication (System.Collections.IList branches, repliKate.RepliKate+RepliKateParams rParams) [0x00025] in <416cafce4578458aace2e15386b62b43>:0

Any idea on what is causing this error?

 

 

[manu]

Oh! I'm afraid that will not work since the cloud is not able to reach "localhost:8087"...

The communication localhost:8087 -> Cloud will work but the other way around will not, you'll need to expose your PC to the Internet with a reachable name.

 

[Lucas]

Ok,

Will it work if I change RepliKate to use the --push switch or perform a replicate --package followed by a replicate --import?

 

I tried a replicate --push manually and got the same visibility error so I'm assuming that wont be possible either:

gilp@maya:~
$ cm replicate "br:/main@areia-art@gilp@cloud" "rep:areia-art@localhost:8087" --push
Error: No such host is known

Now I'm trying to do a manual replicate using --package and --import with no success so far:

gilp@maya:~
$ cm replicate "br:/main/dev@areia-art@localhost:8087" --package=tmppackdev
FetchingFinished. 124 %

Revs: 10 %

Revs: 100 %
Items 35
Revs 69
ACLs 1
Changesets 14
Labels 0
Applied labels 0
Links 0
Applied links 0
Attributes 0
Applied attributes 0
Reviews 0
Review comments 0
gilp@maya:~
$ cm replicate "rep:areia-art@mycloudorganization@cloud" --import=tmppackdev
Time uploading metadata package 835 ms
PushingRevisions. 142 %
PushingFinished. 100 %
Error: Object reference not set to an instance of an object

How can I debug this error? I tried adding a plastic.log.conf and a plasticapi.log.conf files to my client path but no log file is being created.

[manu]

Hello @Lucas, let me summarize it:

Push from local to cloud:

cm replicate br:/main@outrep@localhost:8087 out@myOrg@cloud --push

Push from cloud to local

cm replicate br:/main@out@myOrg@cloud outrep@localhost:8087

Tell me if it helps.

[Lucas]

Hi @manu, It helps a lot!

In fact I was able to  improve RepliKate to suit my needs and  I also made my version of RepliKate available for download at  https://bitbucket.org/gilp/replikate

My changes include three new switches:

replikate srcrepos@srcserver dstrepos@dstserver --mode=[pull|push|sync] --wkpath=path --xlinks=xlink1[,xlink2...]]

--mode
    pull: default mode, pulls changes from source to destination.
    push: pushes changes from soucre to destination instead of pulling from destination
    sync: pulls changes from destination, performs any necessary merges then pushes changes to destination
    
--wkpath
    sets the path to create a workspace named replikate-<repo> when on sync mode. 
    Note: I found the creation of this workspace necessary to perform the eventual fast-forward merge needed
    after pulling.
   
--xlinks
    a comma separated list of xlinks that should be replicated together with the main repo.

 

This way I can setup a cron job with something like:

replikate myrepo@myorg@cloud myrepo@localserver:8087 --mode=sync --xlinks=game-module,art-module,sound-module

And have all repos related to my project synced over night given that there will not be any conflicting changeset to be merged.

 

I'm a total newbie on PlasticSCM and therefore I have no idea if this approach will be good for large projects.  I tried my best for a solution that didn't need an workspace but this was the only way i found to perform the synchronization i need.

I would appreciate immensely if you guys could please take a look at my code and give me feedback about my approach

 

Note: this code was tested on my windows workstation, I'm still to test it on my ubuntu server. Probably gonna do it tomorrow morning.

 

Thanks,

Lucas

 

[manu]

Hi @Lucas!

Awesome work!

I have a suggestion. As the merge you do might end up in conflicts and ruin the workflow I think it would be better to run a merge-to, beneficts:

1) You will know if you can merge the branch without conflicts.

2) You will simplify the code as you don't need to switch to the branch and ci, it's automatically done in the server. (unfortunately you still need to create a wks)

What do you think?

 

[Lucas]

I think it's great.

My first try was actually a merge-to but i couldn't get it to work.

I assume if I can do it without switching to each branch my storage footprint will be almost nonexistent, I mean, the workspace will only contain metadata, it wont hold a copy of the project files untill I switch to a branch or update, right?

Back to the problem, when I perform a merge, there are three things to keep in mind, the base changeset, the changeset to be merged with and the branch where the resulting changeset will reside. On a normal merge I know that the base changeset will be the "head" changeset of the branch I just switched to, and that the resulting changeset will reside in the this same branch. In this sense I only need to inform the changeset to be merged with. But for merge-to operations I found the documentation a little confusing and I couldn't figure which changeset will serve as the base. It would be great if you could guide me on how to do a proper merge-to.

Thanks,

[manu]

Hello @Lucas, 

both merges are really similar. You don't need to know the "base" changeset, that is calculated by Plastic, you just need to know the source (the one you merge from) and the destination (where the result is going to be placed).

For the regular merge you need to switch your workspace to the destination branch, remember that is where you want to place the merge result.

For the merge-to you need to know the source and the destination but you don't need to switch your wks to the destination. The merge-to is used like this:

cm merge br:/main/task001 --to=br:/main --merge

or:

cm merge cs:8857 --to=br:/main --merge

Hope it helps!

[Lucas]

Worked perfectly!

 

Thanks!

[manu]

Great!

Keep us posted when you finish the tool, maybe we can create a blogpost in order to document it.

[Lucas]

Hey @manu,

I just did a few tweaks to the tool:

• Added quotes to all cm find commands in order to work properly on UNIX systems.
• Redesigned how messages are drown to console:
  • Now all messages go through log4net with proper log level setting.
  • This makes it possible customize the console output to your liking (you can have a more verbose or quiet console, colored or black and white output, etc..)
  • Also, the console output is consistent with the generated log files.

 

It would indeed be pretty cool if you could blog about this revamped replikate tool.

[manu]

Sure I'll do!

Great work!