Jump to content

replication probelm


epeleg

Recommended Posts

A Developer I am working with is getting the following error message when trying to push his changes:

------------------

The sync process was unable to replicate the following branch:

Branch: /main/client

Operation: Push

Source repository: Rep@DevelopersServer.com:8087

Destination repository: Rep@OurSharedServer.com:8087

Error description:

There will be conflicts on destination

------------------

How should I go about debugging this?

the shared server is a linux and the developers server is a windows machine.

thanks,

Eyal

Link to comment
Share on other sites

Hi,

Looks like you guys modified the same branch at two different servers in parallel.

No problem.

But, you'll need to "pull" remote changes first, then merge and solve the "multi-head" situation, then push.

See what I mean?

Take a look at "how replication works" here: http://www.plasticscm.com/releases/4.0/manuals-html/en/distributedsystem.htm

Link to comment
Share on other sites

Hi,

Would it be possible to send us the results of the following commands? The command will output a list of changesets on the branch '/main/client' on both repositories (only metadata will be printed, the changeset GUID in fact).

cm find changeset where branch='/main/client' on repository 'Rep@DevelopersServer.com:8087' --format={guid}

cm find changeset where branch='/main/client' on repository 'Rep@OurSharedServer.com:8087' --format={guid}

We would like to check whether there are any conflicts by checking that the list of changesets of one repository is filly included on the other one.

Another option to check this condition could be showing the branch explorer of the branch on each repository (if the branch is not big!)

Thanks,

-Jesús M.

Link to comment
Share on other sites

Hi Jesús,

thanks for helping me with this.

Those are the results for the developer's server:

9b394c65-f775-4dd5-833a-cc36be8f95a1

3d88f17b-83d0-4be2-b1db-2be8d2073482

ba211989-7da7-4470-805e-8395661aacc0

0649fc3b-45cd-45c2-b4b4-d33aea656dda

f4c212dc-9f3c-4f62-a688-e31ca88c57d9

d04b0d8b-1bf4-4f9e-8115-85e942cce70e

922b4f56-e290-4b03-aaf8-8d08708a72f8

1c91c601-d14b-45fa-b631-07610162043c

3a38846d-3f29-4e6d-8504-792d5c73d399

e164ad64-ef58-4fcb-993e-d6a320e471f0

6fbe72e5-9a8f-43a0-ba1c-95f96dccdfde

4c2b9e0f-4efe-43f6-a2e5-6bceff8d9710

16ad58d2-0b30-4f11-b518-26ad29aee273

ff1ebfd9-d044-4b3b-b55d-cc219cc33da0

53dcff38-3388-481e-bc12-e880cf52ed88

c5ab89d6-a183-43b2-9401-5210dd55225f

04f1f6ba-e183-4c59-ade5-9d86d6e4046a

Total: 17

and those are the results for the common server:

9b394c65-f775-4dd5-833a-cc36be8f95a1

3d88f17b-83d0-4be2-b1db-2be8d2073482

ba211989-7da7-4470-805e-8395661aacc0

0649fc3b-45cd-45c2-b4b4-d33aea656dda

f4c212dc-9f3c-4f62-a688-e31ca88c57d9

d04b0d8b-1bf4-4f9e-8115-85e942cce70e

922b4f56-e290-4b03-aaf8-8d08708a72f8

1c91c601-d14b-45fa-b631-07610162043c

3a38846d-3f29-4e6d-8504-792d5c73d399

e164ad64-ef58-4fcb-993e-d6a320e471f0

6fbe72e5-9a8f-43a0-ba1c-95f96dccdfde

4c2b9e0f-4efe-43f6-a2e5-6bceff8d9710

ff1ebfd9-d044-4b3b-b55d-cc219cc33da0

53dcff38-3388-481e-bc12-e880cf52ed88

c5ab89d6-a183-43b2-9401-5210dd55225f

16ad58d2-0b30-4f11-b518-26ad29aee273

ea70db32-24b3-4012-9120-ca5fa75c0224

Total: 17

Link to comment
Share on other sites

Hi epeleg,

can you please try the following in the developer's server:

Right click on the "/main/client" branch, Replication -> Pull this branch...

Then complete the Replication source information (common server) and perform the replication.

Tell us if you can see the following changesets:

16ad58d2-0b30-4f11-b518-26ad29aee273

ea70db32-24b3-4012-9120-ca5fa75c0224

Manu.

Link to comment
Share on other sites

  • 3 weeks later...

Just an update,

I ended up resolving this by connecting directly to the shared server and fixing the two headed branch that was there some how.

We also now better understand to always first pull changes to our own machines,

resolve any potential merge issues and only then push back to the shared server.

Thanks for the assistance.

Eyal

Link to comment
Share on other sites

Cool!

The sub-branches are generated in distributed scenarios where the developers are working on the same branch and they decide to push their changes, since there is no way to fit those changes inside the main line of the branch a sub branch is generated to hold the changes waiting for a merge to unify heads.

Manu.

Link to comment
Share on other sites

Archived

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

×
×
  • Create New...