Synchronization doesn't handle deleted items

Container synchronization is a tough one.  We don't run into your case quite as much, but we do run into instances where we only want to sync some of the items in a set or folder into another project.  If you reuse the source project's hierarchy, you're left with a situation where the container is always out of sync even if that's what you intended to do.  And there's no way to clear that condition like you could with a suspect, so it's always on the out of sync radar.  The only thing we can do as a result is not use the source project hierarchy and only reuse containers if they can be reused in their entirety.  Different issue than the one you described, but it comes back to the challenges of container synchronization.

In principle, I agree... it should be possible to delete items through sync.  But I'll also say that merge logic can get to be fairly complex behind the scenes, and I don't think the sync feature is doing a full-on merge.  The interesting thing here is that we know a container sync isn't using a brute force overwrite method either, since you can selectively add new items via sync.  Ultimately, it could very well be that the source and destination projects don't have enough info stored in the container to know how to reconcile the riskier or more complex merge scenarios.   Adding new items is inherently less risky than deleting existing ones (even if you can restore items), which may be why those work but not deletes.

I agree.  It’s a technically complex but solvable problem.

Hi Mike,
I wanted to let you know that I've been talking a little bit with my Product team about this particular quandary. From the sounds of it we have plans to provide a better cross-project view, however, that work is still in an early design phase so I can't tell you what it might entail, much less give you a time frame for it.

What we're not quite grasping, though, is why you're using reuse and sync for traceability and project status. I can understand the technicalities of the issue—you expect deleted items to be removed from the destination when synced—but I'm not sure how this affects the bird's eye view, which is your ultimate concern.

If you provide me some greater context to this they can understand the true issue you're trying to solve and will consider that when working on this area.

So your "bird's eye" project contains a copy of everything in your entire instance? At this point, what features do you use to manage traceability?

The PM I was discussing this with asked why you wouldn't combine use of the Coverage Explorer with cross-project filters. I think the biggest road block with that is that the CE can be used only for downstream traceability, so if you want to see literally everything, you'd have to have some sort of master item that everything is related to. But if you were open to doing it by the main item types for traceability, it seems feasible. Creating a filter "All requirements" that pulls from All Projects and using it as the first column in the CE would allow traceability down to Test Cases. Of course, you have other important traceability pieces to consider you might have to utilize multiple save Coverage Explorer Views.

We're interested in finding the best workaround for you in regards to this "birds-eye" view, and if we can't find a solution, at least we'll fully understand your needs. I think work on cross-project visibility is going to come before changing the behavior of Reuse & Sync.

Kristina, in regards to this original issue, we have the same need to be able to sync back to a master project and items that were deleted from the secondary project need to be deleted upon syncing back to the master.

Yes, this messes with our expectations too.

We're using reuse and sync to maintain copies of the same block of specifications in two different products. Because they share a block it's necessary that they share an identical copy at all times of the spec. So we've designated one as the master copy and one as the slave copy. Whenever we change a few things in the master we run the sync. A bit manual and cumbersome, but should work in theory.

Deleting an item means that a feature will not be present in the implemented block, and this needs to be reflected in the slave. Right now it shows that the block is out of sync, but we can't do anything about it from the sync window, we need to go back to the slave block with a list of differences and manually do the deletions.

It is really bothersome, especially as the ability to sync all changes shows so much promise for other types of changes. But often what you don't include is just as important as what gets included.

We've considered using embedded links as a workaround, so instead of reusing the block we just have an item with a link "click here for all the shared stuff", but this really fragments the readability of the spec.

Since this is obviously a key need for users of Jama reuse, when can we expect this functionality to be incorporated?