Welcome to the Onshape forum! Ask questions and join in the discussions about everything Onshape.
First time visiting? Here are some places to start:- Looking for a certain topic? Check out the categories filter or use Search (upper right).
- Need support? Ask a question to our Community Support category.
- Please submit support tickets for bugs but you can request improvements in the Product Feedback category.
- Be respectful, on topic and if you see a problem, Flag it.
If you would like to contact our Community Manager personally, feel free to send a private message or an email.
Merging to bring a tab into a branch
shawn_crocker
Member, OS Professional Posts: 869 PRO
I have a concept I'm trying to test the plausibility of. I make a branch. I delete everything in the branch except one tab and then create a version. In the main branch, I delete that one tab that was left in the new branch and I then create a version. When I merge the new branch back into the main branch, I get a workspace that has nothing in it. How can I rearrange the steps I am taking so that I end up with the main workspace just like it was before the merge but with the tab from the other branch merged in?
Tagged:
1
Best Answers
-
romeograham
Member, csevp Posts: 682 PRO
What about removing your tab deletion steps? I think you don't want to delete all the other tabs - that's telling Onshape "I don't want these tabs" so when it merges from the Source Branch to the target branch, it removes them. I think the best thing is to leave the ones that you don't want to change unchanged...so the merge has no effect.
(if you have successfully merged workspaces / branches in the past while deleting the tabs that will be replaced - and it's not working this time - I don't know what's going on. I do think that the very existence of tabs is part of what gets merged....so you are telling Onshape that you don't want some of your tabs at all, not that you want to replace a tab that doesn't exist with a tab that has your desired features in it).
0 -
eric_pesty
Member Posts: 1,947 PRO
Couple more thoughts, obviously it depends on your actual scenario...shawn_crocker said:@eric_pesty
One issue I have with merging the winner is that, it is the winner. If I merge it, suddenly it will no longer be the same as it will take on some of the features of the other branch.
The way I would typically use a branch is to develop "one aspect" of the design, say a bracket and design one in sheet metal and one machined (made up scenario) in two different branches. These branches would only have the changes relevant to this bracket (mounting holes in another part for example), but I might be waiting for quotes to decide the winner and want to work on some other aspect of the design (say a cover). Assuming the cover design isn't affected by the bracket, I would do that work in the "origina" branch, and then later I can pick the best of bracket design and merge that branch (and only that branch!) so I end up with new cover I designed in the main branch and the bracket. And maybe I have to do some tweaks in the cover if the bracket did affect it after all...
Another scenario is if I am going to do some major design concept changes in a couple separate branches to "test them out". In that case I probably won't be making any changes in the original one so that when I merge back the original is the same as the winner.
One third potentially related thing to be aware of that I think would be the answer to your question above is that, if for some reason you did make changes to your original branch while you were working on your concept branches, but want to discard them (so that it's only the "winner" that remains), that is easy to do: all you have to do is restore the main branch to the version you created your branch from before merging, this results in your "original" branch being exactly identical to the "winner" your merge in. Hope that makes sense!
Edited to add:
The one thing you want to make sure you don't do is make changes "same thing" (and I mean the same "design feature" for example edit the mounting hole of the same bracket in two branches that are going to be merged, then you will have a conflict when you try to merge. But it's ok to edit the mounting holes in one side of the bracket in one branch and the "other end" in a separate branch as these will still "play nice" after merge.
1
Answers
(if you have successfully merged workspaces / branches in the past while deleting the tabs that will be replaced - and it's not working this time - I don't know what's going on. I do think that the very existence of tabs is part of what gets merged....so you are telling Onshape that you don't want some of your tabs at all, not that you want to replace a tab that doesn't exist with a tab that has your desired features in it).
Just no need to delete the stuff that's getting replaced (or is unchanged)...that's what the "merge" is for!
You can create that new tab in your main branch and work on it (or even in a different document and "move it in" after)...
Branching is when (one example use case anyway) you want to test some changes to your existing stuff but not sure if you want to keep it. Or maybe you need to modify something but there are two ways of doing it you want to investigate (each requiring some changes to multiple tabs) so create two branches to test out the two concepts "in parallel" and then only merge the "winner".
One issue I have with merging the winner is that, it is the winner. If I merge it, suddenly it will no longer be the same as it will take on some of the features of the other branch.
To put this branching thing another way. I'm trying to use branches as a separate document. Why not just use a separate document? Because it makes it annoying when the parts are almost certainly only going to be used in the top level product assembly. Its nice for releases to all be nice and tidy in the same document. Separate documents is also not as clean I have found starts feeling like I'm working with files again with stuff flying all over the place. Its also annoying to do additional major development with versioning. I can move the tab into the document for changes and then back out but it feels wrong. Not being able to effectively get the tab with proper associativity back into the main workspace is what is killing this branching method I am attempting to try.
I will probably continue the same as usual. Create a versions for special items and switch items to reference back to there designated versions. It works extremely well but I just don't like to see many in progress, basically redundant versions of these special items in the search. I feel like I am bloating things up for some reason.
The way I would typically use a branch is to develop "one aspect" of the design, say a bracket and design one in sheet metal and one machined (made up scenario) in two different branches. These branches would only have the changes relevant to this bracket (mounting holes in another part for example), but I might be waiting for quotes to decide the winner and want to work on some other aspect of the design (say a cover). Assuming the cover design isn't affected by the bracket, I would do that work in the "origina" branch, and then later I can pick the best of bracket design and merge that branch (and only that branch!) so I end up with new cover I designed in the main branch and the bracket. And maybe I have to do some tweaks in the cover if the bracket did affect it after all...
Another scenario is if I am going to do some major design concept changes in a couple separate branches to "test them out". In that case I probably won't be making any changes in the original one so that when I merge back the original is the same as the winner.
One third potentially related thing to be aware of that I think would be the answer to your question above is that, if for some reason you did make changes to your original branch while you were working on your concept branches, but want to discard them (so that it's only the "winner" that remains), that is easy to do: all you have to do is restore the main branch to the version you created your branch from before merging, this results in your "original" branch being exactly identical to the "winner" your merge in. Hope that makes sense!
Edited to add:
The one thing you want to make sure you don't do is make changes "same thing" (and I mean the same "design feature" for example edit the mounting hole of the same bracket in two branches that are going to be merged, then you will have a conflict when you try to merge. But it's ok to edit the mounting holes in one side of the bracket in one branch and the "other end" in a separate branch as these will still "play nice" after merge.
I mean I understand how you can and how it works but at that point why merge them?
Or to put it another if you ARE going to merge them, why create the branch in the first place? And maybe that's the key, I guess I don't really understand what the benefit of using branching would be in what you are trying to do, i.e. what are you trying to achieve with branching that you can't do by just creating a new tab in the main branch?
Thanks for the expert insights. I will play around with combining restoring and merging. I feel like you could be onto somthing there.
I get the part about "not versioning something" that isn't actually getting changed which does happen a lot when you have a project in a single document...
I've kind of learned to accept that this was going to happen although it can be annoying when the part is also used in another document (where it ends up "out of date" all the time). I wish you could "pin reference to a branch" so that you could automatically ignore any new versions created in a different branch (but still get a notification when the branch it's in gets updated), that would help...
I think the intended way to handle this is to move these to a different document (and maybe use a folder to keep them "together").
It seems like what you are looking for is a "move to branch" function, similar to "move to document".
This could actually be done by the "move to document" command if it let you move to the same doc (and pick a different workspace). It can be done right now but you have to move it out to some other document (even a temporary one), and then move it back from there to the other workspace. That's a few more steps obviously and creates versions in the process so I am not sure how much that helps...
I've created an IR to allow "move to a different workspace":
https://forum.onshape.com/discussion/18457/allow-move-to-document-to-select-itself-as-the-destination-to-move-to-a-different-workspace/p1?new=1
I actually have an improvement request open called "
UPDATE PART VERSION ONLY WHEN NEW VERSIONS EXIST IN THE SAME BRANCH"
It deals with what you have said here. "I wish you could "pin reference to a branch" so that you could automatically ignore any new versions created in a different branch (but still get a notification when the branch it's in gets updated), that would help...".Being able to directly move a tab to a new or existing branch within the same document would most certainly resolve this desire I have. I may go ahead and make a request for this if one isn't already made. There is an article out there discussing this but I can't remember if it was an improvement request or not.