

I also want locally deleted files to be deleted on the server.
Sometimes I even move files around (I believe in directory structure) and again, git deals with this perfectly. If it weren’t for the lossless-to-lossy caveat.
It would be perfect if my script could recognize that just like git does, instead of deleting and reuploading the same file to a different location.
If you were to use Git, deleted files get deleted in the working copy, but not in history. It’s still there, taking up disk space, although no transmission.
I’d look at existing backup and file sync solutions. They may have what you want.
For an implementation, I would work with an index. If you store paths + file size + content checksum you can match files under different paths. If you compare local index and remote you could identify file moves and do the move on the remote site too.


That’s a very one-dimensional view of technical debt.
I was about to write something more, but I think if I don’t know what they refer to when they say “knowledge”, then it’s too wishy-washy and I may be talking about something different than they intended.
Contrasting “resolving technical debt” and “investing [improvement] knowledge” we’re moving the reference view point.
I document state and issues as technical debt, and opportunities for change as opportunities. They cross, but are distinct concepts, and do not always cross. Some technical debt may be documented without a documented opportunity. Opportunities may be open improvements that do not tackle technical debt.
In my eyes, technical debt is about burdens that reduce maintainability where better alternatives likely exist.
“Investing knowledge” is something different, and not necessarily about known burdens, but may be improvements unrelated to known burdens.