Edit target asm

[ethteck]

Aside from the design ramifications of this (asm being shared among scratches, how this will affect forks and parents, permissioning), we need to consider that the asm in the db will need to be re-assembled and all. idk just some random thoughts - will flesh this out later

[ethteck]

Ideas:

• Editing target asm only affects all children of a fork and breaks the current fork away from its parent, creating a new Asm/Assembly object with different information (shared by all children)
  • For project functions, only the project members could edit base asm
• Editing target asm is a frontend-only feature, in that you can send custom asm to the /compile endpoint to see what the score would be if the asm were different. but it doesn't actually modify the asm in the database or affect the score

[bates64]

FWIW I'm still on team 'immutable target asm'. If the people who want this feature can provide some cases as to when they see themselves wanting the feature, perhaps we can get a better idea of how to tackle the problem. Right now I think it will cause too many problems with respect to forks, parents, scoring, and the relationship between them.

[bates64]

All the cases I can think of where a user might want to edit target asm would be effectively solved with a "duplicate scratch but with different target asm and prompt to archive the old one" feature

[ethteck]

unfortunately target asm just isn't always accurate, and so manually fixing it is required to get things to match / fix symbol names / correctly annotate hi/lo pairs or what have you. so I definitely see the need to edit it and why it's inconvenient to go back to the new scratch page just to effectively edit the asm

[ethteck]

Right now I think it will cause too many problems with respect to forks, parents, scoring, and the relationship between them.

I think the ideas I presented above wouldn't be that bad in this regard

[ethteck]

duplicate scratch but with different target asm and prompt to archive the old one

I think this sounds good in theory, but what if you need to keep trying new things? Making a bunch of new scratches just seems unnecessary

[ethteck]

Okay, here's my new recommendation on this:

A user can edit the target asm, and we create a new scratch for them with a new target_asm object in the database.

They're told this will split the scratch away from its current ancestry *. They're also prompted for whether they want to delete (or archive) their existing scratch before being navigated to the new scratch page.

• If we want to preserve the family in this situation, we can stop basing families off of target_asm and instead go off of highest parent or something