syncany-team team mailing list archive

[Philipp Heckel <philipp.heckel@xxxxxxxxx>]

Hi again,


I know and I'm sorry to say that I really really dislike it, for
> starters because you are only postponing user's intervention without
> clearly saying that you need his/her intervention. In fact it's even
> worse than that, simply because there is no way to make this renaming nice.
>

I think we might have hit a dead end here. I really like the rename-resolve
method (and so do many others). I am certainly not going to stop you from
implementing something more interactive -- in fact, if you want this really
badly, I can help you design/implement it -- but my focus for now will be
an automatic renaming concept.

If you really want interaction, I see (not so tiny) problem: Right now, we
only know about file conflicts in the FileSystemAction, so at the very end.
That would mean that you'd have to potentially ask many times -- at least
with the current design.

(...)
> In the first case the user file is modified without his/her consent.
> This is against all common sense (starting with the principle of minimal
> surprise). In particular Unices do not lock files under editions: let's
> say I'm happily editing some files under emacs with unsaved
> modifications on foo.txt and bar.txt. I decide to save bar.txt,
> triggering the sync up operation. I've to do a down before. If this is
> done automatically, bingo, my non saved file foo.txt (which wa modified
> on the remote) is silently updated on disk. If this is not done
> automatically, I will be notified of the possible conflict (this is
> database wide so there might be actually no conflict). I've then to
> remember to save everything before manually starting the down and
> manually inspecting the possible conflicts. This is insanely complicated
> and dangerous.
>

That is probably true. It's not only emacs, it's also gedit or even Eclipse
...

On the good side, however, we have versioning and can get the overwritten
stuff back (if we realize that we did overwrite something ...)


> The second solution is less dangerous but super annoying because it is
> unstable: (...)
>

Not really an option, I think ...

Best
Philipp