Replicating wrong target

[Soho]

In the sync view I just accidentally added an additional target repository to the wrong source repo and started replicating. This totally messed up my repo and I probably have to deleted and sync it all over.

The blunder was because the added target was an xlinked repo and in the morning haze it felt intuitive to add it to the same source as the main repo. Also because writable xlinks use the same branch names, the branches to be synced looked ok.

Obviously this was wrong and even though I cancelled the transfer midway the damage was done and I see no way of undoing it.

May I suggest that you add some kind of sanity check when targets are added to sources that already have a target. For example give a warning if two targets are added does not look like they point to the same repo.

This is a very easy mistake to make and the consequences are pretty grim. When using xlinks it really feels intuitive to just add the targets to the same source even though it is wrong.

Just before I nuke my repo and start resyncing, is there any way to undo the damage?

[vsanchezm]

Hi Soho,

The protection you are asking for, is complicated. There is nothing to associate a repository with another. We will study it but there is no solution that fits all scenarios.

In order to fix your blunder, you could delete all objects associated with the replicationlog associated to the replica you carried out; but, it is a task far from trivial.

[Soho]

I assume that the idea of multiple targets is to allow true serverless ditributed repos, such that a group of developers just sync between each other's repos (git style).

However, it must be unusual to add multiple targets to the different repos on the same target server, especially if the source repo already has content.

This could be a trigger for a warning dialog. "Warning, you are adding multiple targets to different repositories on the same target server. Continue?".

A simple repo similarity measure should also be straight forward. When adding a target to a repo with content, you could check if one of the repo, source or target, contains branch names not found in the other repo. This could issue a warning.

A third check could be that the target repo name matches another repo on the source server. This could suggest that the user really wanted to map that repo.

A forth check could be that the target repo being added is an xlinked repo to an already mapped target repo. I can't think of any reason why a user would want to make that sync configuration.

These warnings would be a tiny tiny inconvenience compared to the mess someone like me is likely to make in the future. Especially if using lots of xlinks. There are lots of things to associate repos with one another.

[vsanchezm]

Yes, you are right. I will talk about it with the team.

Btw, I wish your blunder can be solved easily

[Soho]

I was lucky. I had no pending exports in my source repo, so I could easily start over.

[Soho]

Now I am at it. The whole issue is really about syncing repos with xlinks. The best solution for me would have been if Plastic automatically detected the xlinks when I created the view.

I imagine a scenario like this:

I click add new sync view.

Instead of clicking add new source as I am supposed to now, I click "add new target".

I choose the target on a target server.

Plastic detects that I already have a repo with the same name on my source server (or use some other similarity measure as I have suggested above) and ask if I want to use that source repo, another source repo or create a new.

Plastic detects that the target repo has xlinks. For each xlink Plastic repeats the above check for a source repo and offers to use that, another or a create a new.

By using a target first approach, this would eliminate the risk of the above error and be very convenient.

Combine that with a button for syncing all targets and you have a near perfect sync view system.

[manu]

Hi Soho,

I find your replication improvements very interesting, can you please add them into the user voice system? We will try to get the implemented in the next sprints.

[Soho]

Idea added to user voice.

[manu]

Thanks!