Jump to content
Mikael Kalms

Working in parent repo sometimes results in empty commits in wxlinked sub-repos

Recommended Posts

Hi,

we have a repository which the entire team works within, and then we have 5 sub-repos that are wxlinked within the parent repository. People are normally working within the parent repository only -- changes within the sub-repos are very rare.

 

For some reason which we do not understand, when people work normally in the parent repository, corresponding branches are being created with empty changesets within the sub-repos. This pollutes history within the sub-repos, causes confusion ("what are these extra 5 items in this merge?"), and makes the Incoming Changes view fail (it doesn't handle merges in sub-repos).

 

If possible, we would like to find out why these empty changesets & extra branches appear in the sub-repos -- and, if possible, stop them from appearing in the future.

 

I'm not sure exactly about the conditions under which this happens. I find it difficult to reproduce on my own, when there is no activity from others in the repository.

For example, I tried this just now, and it did not happen: I created a child branch, checked in a change into that child branch, merged up from child to parent, checked in a change into the parent branch, merged from parent to child. I think it is much more likely to show up if there is concurrent activity from users. (Not necessarily two operations running at the same time, but perhaps two branches need to exist with partial overlap in time.)

 

One thing that I have noticed is that whenever this happens, all 5 sub-repos will end up with branches & blank commits, and during subsequent merges all 5 wxlinks will then get updated. If I look back through history there doesn't seem to be any cases where 1, 2, 3 or 4 sub-repos are affected; it's either all or nothing.

If I look at the Branch Explorer within one of these sub-repos, it becomes evident that the empty changesets are strictly related to merge operations (see attached image).

 

 

To put some numbers on this,

there are ~20 developers working within the parent repository.

Between Feb 11th and today there have been about 650 branches in the parent repository, and about 430 branches in each of those sub-repos (out of which 99% are unintentional and contain empty changesets).

empty_changesets.png

Share this post


Link to post
Share on other sites

Hi,

The main reason for having an empty changeset: 

- You created a "/main/task001" branch including some changes in your Xlinked repo (some other changes may belong to the parent repo).

- You perform the same changes in your Xlinked repo but this time in the "/main" branch.

- You merge "/main/task001" into "/main" and checkin the changes.

1) If you review the merge result changeset in the parent repo yo will see the merged file revisions.

2) If you review the merge result changeset in the Xlinked repo, the changeset is empty. There was no file revisions to merge in the Xlinked repo because they were already existing on the main branch.

There may be some other scenarios for some empty changesets but this is the most common scenario.

NOTE: Not sure how this workflow can make the "Incoming changes" to fail. This problem happens when the Xlink is not pointing to the last (and a merge is necessary inside the Xlink).

In my example, the Xlink is automatically updated to the last changeset after the merge no merge should be needed in the Xlinked repo when you try to update your workspace via "Incoming changes" view.

Regards,

Carlos.

Share this post


Link to post
Share on other sites

What you describe does not match my experience.

 

1. I created a "/main/task001" branch in my parent repo.

2. I made changes in my parent repo.

3. I probably merged from "/main" to "/main/task001" while working in my parent repo. At this point, sometimes I see updates to the xlinked sub-repositories.

4. I was done with my task, so I merged from "/main/task001" to "/main" in my parent repo. At this point, sometimes I see updates to the xlinked sub-repositories.

 

I never made any intentional changes to anything in a sub-repo. This is still resulting in new branches & changesets within sub-repos.

Share this post


Link to post
Share on other sites

Hi,

1) When you create a task branch and then checkout a file belonging to the Xlinked repo, a task branch is also created in the XLinked repo.

2) Then, all the changes you perform in the parent repo belonging to the XLinked repo will be propageted to the Xlinked repo creating new changesets in the branch created on step 1.

3) Finally ehen you merge the branch in the parent repo, the same merge will happen in the Xlinked repo. If the changes merged in the XLinked repo already exist on the parent branch, an empty changeset will be created (nothing is merged).

Regards,

Carlos.

Share this post


Link to post
Share on other sites

Carlos, you misunderstand me.

What you describe above makes total sense. However, my situation is different: I never change any files that belong to the Xlinked repo, yet Plastic (sometimes, not always) creates commits within the xlinked repo. This seems to happen either in none of the  xlinked repos, or in all 5 xlinked repos - never 1,2,3 or 4 of them.

I do not have a good repro case for this either; I suspect it is something that happens when many people are working concurrently (and make good use of branches) within the same main repository.

Perhaps our main repo and/or sub-repos have ended up in a bad state? I do not know.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...