Merge footprint

[Soho]

I am trying to find a workaround for a bug in Plastic causing it to crash when branches are merged to /main.

Since the branches were branched out from /main another branch with a lot of test data has been merged to /main.

Since I cannot merge branches to /main my question is:

What happens if I merge /main to the branches and then back again to /merge?

Specifically, can I expect the /main -> /main/branch_without_large_dataset merge to generate a lot of files and lots of GB in the repository database versus a /main/branch_without_large_dataset to /main merge?

I ask because the merge dialog will show a ton of files if merging one way, but only a few files when merging the other (as expected), but I don't want the large merge if that leaves a large merge footprint and if I can avoid it.

[vsanchezm]

Hi Soho,

I understand you have used the subtractive merge in order to remove the changes of some branches from main and now you want to reintegrate those branches in main again, am I correct?

If this is the case, of course you can merge the branches back to main.

Follow the next steps:

1. Cherry-pick without tracking from the changeset where the branch was previously merge.

To do that, when performing the cherry-pick, in the merge options panel, click on the "Ignore merge tracking" option.

2. Merge again the branch.

Let me know if it helps.

Thanks in advance

Violeta

[Soho]

I understand you have used the subtractive merge in order to remove the changes of some branches from main and now you want to reintegrate those branches in main again, am I correct?

No, my problem is that Plastic crashes for unknown reasons when I try to merge some branches to /main.

My question is about the consequences of a work around where I merge the other way, from /main to /main/branch and then back from /main/branch to /main.

I ask because since I branched out /main/branch from /main about 20.000 files have been added to a writable xlink repo in another branch that have been merged to /main.

If I try to merge from /main to /main/branch I obviously get those 20.000 files in the merge view and I am worrying that this will generate a lot of garbage in my repo that will potentially slow down Plastic or at least take up some space in the database.

What I really want is /main/branch, containing a few important changes, merged to /main, but probably because of some issues with writable xlinks this is not possible, so I am looking for the least intrusive work around.

[vsanchezm]

Ok. So, is the same problem that you reported at and ? Are all of them the same? Or are they different?

In that case, let's try to follow a single thread and isolate the problem better than give you a workaround.

From the stacktrace you posted, the error comes during the checkin operation and not during the merge operation, right?

Also, I spot in the stacktrace that the checkin operation is calling the merge, so a merge is needed in order to carry out with the checkin. This might be because your xlinks are outdated as I was pointing to before.

Let's verify it.

Could you check if the changesets where your xlinks are pointing to are the last ones in the branches in the xlinked repositories (in main branch)?

Otherwise, they have to be up-to-dated in order to carry out with the merge.

[vsanchezm]

About the work around you are pointing to, the answer about your worries is not, not consequences or damages for Plastic.

This won't generate garbage in the repo, the revision of those files are already stored so they won't be stored again.

[Soho]

This won't generate garbage in the repo, the revision of those files are already stored so they won't be stored again.

I didn't expect Plastic to store the data content of the files again, but perhaps 20000 references would be inserted.

[vsanchezm]

Sorry, I meant the references. They won't be inserted again.

[Soho]

Could you check if the changesets where your xlinks are pointing to are the last ones in the branches in the xlinked repositories (in main branch)?

/main doesn't contain the newest changesets for all xlinked repos. Some of our branches have made updates to the xlinked repos. Since these are writable xlinks the changes in the xlink repos are autobranches named accordingly to the subbranches of /main.

I don't just want to update /main with the latest changeset in the referred xlinks since the latest changeset are in auto-subbranches and would require a merge to /their main before I could make an update.

I suppose I could manually merge all branches in all referred xlinks to their /main and then update the "main" repos /main to those changesets. Afterall this is what I expected Plastic to do for me.

If Plastic doesn't handle changes in writable xlinked repos in subbranches in other than ideal scenarios, I suppose writable xlinks are best avoided.

Would you replace that we disable writable xlinks with non-writable xlinks?

Writable xlinks seem not fully thought through.

[vsanchezm]

No Soho, you misunderstood me. Maybe I have not explained clearly.

Of course Plastic does for you the merges of the autobranches created in the xlinked repos. You don't have to merge manually the branches. This is the purpose of writable xlinks and so they are so useful.

I just want you to check, in your main branch, in your main rep, where those xlinks are pointing to. Are those changesets the last ones in the main branches (not in the autobranches created!) in the xlinked repos?

Do I explain better now? If it is still not clear, I can establish a connection with you to check it.

[Soho]

Ok, I was finally able to merge my branches to /main (hurray!), but took several attempts with maybe 3-4 different exceptions.

First I tried just updating all xlinked repos in /main to the latest, but that wasn't enough. For starters I couldn't merge one of the branches, the "process merges" dialog just kept showing files even though I pressed "process merges". I then tried merging another branch at it succeeded in two attempts. First it failed with the "item not found" error again (and a null reference). It turned out that the merge had also merged the xlinked subbranches, so once again /main was behind in changesets. I couldn't update the xlinks though. Plastic complained that this was not possible since there were changes. I then undid the merge, which did NOT undo the derived xlink merges. I was then able to, once again, update /main to the latest changesets and I could repeat the merge and the checkin worked.

This had to repeated for all branches with changes in the xlinked repos. In this process I stumble into a wide array of strange Plastic exception dialogs.

My current situation is that I have merged all my branches, but pending changes contains a pending merge link that I cannot undo and cannot checkin. It just stays there, which obviously gives me some problems.

I can probably workaround this by deleting some merge state files in ".plastic", but this is not for the faint-hearted.

All in all, a lot of issues just because I wanted to merge some branches to main.

So, my questions remain. Are wxlinks experimenal and risky in their current state and would you recommend that I switch to non-writable xlinks?

[psantosl]

Two things here:

* If you use writable xlinks, my recommendation would be: do not modify the xlinked branch outside the xlinked repo. I mean, if you access "comp2" from "project" do it this way, not with a wk directly working on the xlinked repo

* If you don't need to modify the files: use readonly xlinks.

[Soho]

* If you use writable xlinks, my recommendation would be: do not modify the xlinked branch outside the xlinked repo. I mean, if you access "comp2" from "project" do it this way, not with a wk directly working on the xlinked repo

Sorry for being a bit slow here, but I am not completely sure what your recommendation is exactly. "do not modify the xlinked branch outside the xlinked repo". Do you mean, that my repo "Superproject" xlinks to the "MyLib" repo and I make a branch "fix10" in "Superproject" (causing a similarly named branch in "MyLib"), I should only make changes to MyLib:Fix10 in the "Superproject" workspace and not in a dedicated "MyLib" workspace?

If so, this is what we have done. I don't recall modifying xlinked repos in dedicated workspaces in this case. Here are some other circumstances that I suspect could have confused Plastic:

• Some xlinked repos are nested. "Superproject" refers to "MyLib" referring to "MyCoreLib". In some branches of "Superproject" changes have been made in all xlinked repos.
  
• Changes to xlinked repos have been made in multiple branches of "Superproject" as well as /main simultaneously before the branch merge with /main were attempted.
  
• Replication have been used (all branches have been replicated) and xlinked repos have been changes in the replicated repos (we have used relative wxlinks).
  

I should also say that writable xlinks is a feature I have been missing for years. It is the classic problem. How do I make changes to a shared library without disturbing other projects referring to that library? Writable xlinks seemed to be the perfect answer and I really hope you stabilize this feature, because it is a killer compared to other VCSs.

Until then we are facing realities. We were so excited by the feature that we went all in with wxlinks for several projects. Unfortunately wxlinks are flawed which is a major problem when you rely on that feature as a core feature.

This is why I ask what use of wxlinks you consider safe.

[Soho]

Here is a fresh wxlink issue.

in /main in my "Super" project I editied some files in "Commons", an wxlinked library shared among many projects.

I tried to commit those changes and voila, I got the "item xxxx not found error". As I understand it, this is because my "Commons" xlink were not pointing to the latest changeset in "Commons:/main" when I started editing (I forgot to check).

Now I have no idea how to checkin those files expect backing up Commons, updating the xlink to the latest commons changeset and then restoring the backup and committing the changes.

If two different projects can't make changes to the same wxlinked repo I see little use of writable repos.

[Soho]

I tried the backup "hack" described above and Plastic threw this at me:

What does this mean?

It is true that I replaced "CommonsTest.csproj with a backed up file, but what is wrong with that?

Eventually I undid everything, checked out CommonsTest.csproj and then replaced it. That worked, but why was the checkout needed?

Is this because Plastic uses file timestamps to determine if an item is changed or "inconsistently changed"?

If so, the error message is not very specific about this being the problem.

[manu]

Hello Soho,

you are getting the error due to your workspace is not completely updated, the revision you are having in your workspace is not the one you should have. Maybe a switch update with changed items?

You have to undo the changed and update your workspace, then you can copy the file again and commit it.

Here you have an example about how to reproduce the issue:

1) Add fooc.c in /main branch (revision 0, changeset 1)

2) Create a branch from cset 1 called scm001, switch to it.

3) Create a new revision of the foo.c file (revision 1, changeset 2)

4) Switch to /main branch, change (no checkout) the foo.c file, edit it with some content.

5) Switch to /main/scm001 branch with the changed item and try to commit.

You will get the error since the revision in your workspace is the 0 instead of the 1.