never actually delete anything

[roambotics_scott]

Perhaps I'm just being superstitious here but I'm convinced that one of the longer standing causes for instability and general flakiness is that certain data structures are actually deleted rather than being flagged deleted.

One case where I think I'm running into that is the following:

1) Create new design using timeline

2) create component

3) create bodies extrenal to component

4) combine / join bodies to component preserving the originals

5) try to delete originals

This should «just work» but instead when I do it, I get a warning

and then if I go ahead, it breaks the dependenc(ies)

This should never happen. 

If someone deletes or changes something in the present, it should never break things in the past. That's not how causality works and it shouldn't be how the dependency graph works.

Instead, it should have a new [delete] operation added to the present on top of the existing body that hides it and effectively removes it from the current assembly without breaking anything.

[kb9ydn]

When you delete the original bodies you are deleting them in the past, not the present.  So after the delete it is as if they ever existed, and anything beyond that point could be affected.  What you're looking for is a delete from the present time (I would call this "remove" instead of delete, but that's just semantics).

I think both types of delete (past and present) have their place so we should have both types.

C|

[roambotics_scott]

Yeah I get that I'm deleting them from the past but it's fundamentally wrong.

I never rewound time it's wrong to break things in the past based on an action a user takes in the present. The behaviour would be reasonable if I had.

[kb9ydn]

Ok, I see what you're saying.  In order to delete something in the past you should have to roll back the timeline to that point first.  I can see the logic behind that but I think having it work that way would be more annoying, because most of the time I want delete to be a past delete and not a present delete.  Having to roll back the timeline every time I want to do a past delete would create a lot of extra work for nothing.  It also would be somewhat against convention (Solidworks convention anyway, not sure about other programs).

I also think defaulting to present delete sort of encourages a messy timeline because every delete adds another entry.

Perhaps this falls under one of those user preference settings where you can choose what the default delete action is.

C|

[roambotics_scott]

IDK to me deleting from the past by default seems horribly counterintuitive.

Unless the user intentionally rolls back the clock, every action should have minimum side-effects and as it is, it's just a mine waiting to explode when a user does something obvious.

[kb9ydn]

In the end I suppose it comes down to what you are used to.

But with a past delete it should pop up a confirmation warning (if you want it to) that shows what other features will be deleted along with whatever you have selected.  This way you get at least some warning (before you commit) that there may be unintended side effects, even if you don't know exactly what they are.

And of course you should be able to undo any delete action, past or present.

C|

[roambotics_scott]

In the end it should come down to what's best.

It does pop up a confirmation warning (see OP) and you can undo but there isn't even an option to just delete in the present without the side-effect which means that because I didn't notice I had «keep tools» ticked when I merged some things, I'm now stuck with a handful of extraneous bodies that I can't delete without breaking things or turning off the timeline.

[phazaar]

Just a note that the real problem (as this discussion has demonstrated) is the lack of a consistent 'Remove' command, NOT 'Delete.'

In many instances, 'Remove' is an option, creates a timeline event and is chronologically valid (i.e. doesn't mess with dependencies). All too often though, 'Remove' is not an option (I have yet to work out when it is and isn't...) leaving you with the option to either delete (from all time) and rework any parts you wished to be retained, or create extra features to 'Cut' away whatever you wished to remove.

As ever, inconsistency is the root cause of most virtually any user interface issue.

[roambotics_scott]

Eh.. as someone with a lot of experience with version control and versioned databases, I'm going to go ahead and disagree with you there.

Doing anything with side-effects is dangerous and should be taken very seriously, and rewriting history is almost always a bad idea.

The whole point of version control is that the user can roll the clock back.

Creates a program under version control, create a file, do some stuff with it, and then delete that file, commit regularly, roll back to before the file was deleted. You'd keep the file deleted, which would mean that the program is broken even though it would have worked when it was committed. 

Sorry, but that's just wrong.

I'll give you that there shouldn't be both remove and delete, and that it should be consistent, though.

[kb9ydn]

With a version control system it is of course required that an immutable running history be maintained, but I don't think it's really the intent of the timeline to be quite that strict.  I've been doing history based modelling in SWX for years now and I fully understand the ins and outs of managing feature history, including deleting things in the past and present.  And to me, they are both necessary.  When doing past deletes you do have to be very careful about managing side effects, but please let me decide for myself whether or not it's worth the risk.

Even if the option for past deletes is hidden behind a user preferrences option, that would be fine as long as there is the option.

C|

[roambotics_scott]

I'm not saying «get rid of deleting it in the past». You could easily do that - just roll back to when it's created and delete the thing.

.. but it shouldn't be a default behavior that a user can easily trigger unintentionally.

If you want to create side-effects, it should be a deliberate choice. 

I create and delete things all the time, but I can't think of many good cases where it'd actually make sense to remove them from the history (in fact, even if you're just using them as a reference, it'd be wise to keep the data structures in memory just so F360 can maintain links through the design).

Actually in all the time I've used Git, RCS, CVS, etc, I can only think of maybe once where I actually wanted to remove something from history (save for accidentally committing something like a cryptographic key to version control that shouldn't have been included).

I'm very curious to hear one or two of your use cases where a hard delete from history is actually the preferred behavior.

[kb9ydn]

Usually when I want to do a permanent delete it's because I've found a better way to model a particular feature and I just want to remove the previous attempts from the design completely.  Leaving them there would clutter up the history for no good reason.  Sometimes I'll create a copy of a part if I just want to try something out, but generally not because then I have to delete the file if it turns out to be a dead end.

I think it would be ok to have the default delete action be a *soft delete* that operates at the present time and then have a check box to click if you want a permanent delete.  Then it could pop up a warning window that lists what features might possibly be affected with the permanent delete.

C|

[colin.smith]

This item has been archived due to a lack of votes. If you feel this item is important feel free to create a new idea station item.