Re: [Monotone-devel] update and other commands vs missing files

[Stephen Leake]

Thomas Keller <address@hidden> writes:

> Stephen Leake schrieb:
>> Why does 'update' care if some files are missing? They will be
>> restored or not as appropriate by the update anyway.
>
> Yeah, a few user complained about that already (especially in
> conjunction with the status command you've also listed below) - under
> certain circumstances (i.e. read-only operations) I'd like to see this
> message go away as well, for write operations I'd still like to stick
> with them.
>
>> Other uses of update_current_roster_from_filesystem:
>> CMD_AUTOMATE(get_current_revision)
>>     'missing' files should show as deleted; should not abort
>
> No, get_current_revision should only list those files as deleted which
> have been actually recorded for deletion by the user. 

Ah. I guess I'm saying mtn should interpret the user action of deleting
the file from the workspace as also intending to delete it from mtn;
the user should not be forced to do 'mtn drop'. That is a somewhat
radical change. I would welcome it!

>> cmd_diff_log.cc prepare_diff
>>     'missing' files should be shown as 'only in other'; should not
>>     abort
>
> Even if the user restricted to a particular missing file? Whats the
> point of such a diff then?

It depends on what the user is doing. They deleted the file, so why
are they trying to diff with it? 

I think this means there should be more user control over whether
'file system only delete' should be the same as 'file system and mtn
delete'. Then there's 'mtn only delete', which is even more confusing.

>> CMD(get_roster)
>>     'missing' files should show as deleted; should not abort
>
> I wonder if its a good idea to have this command around - rosters are
> internal throw-away cache structures which should just not be exposed
> anyhow to the user. Is anybody already relying on get_roster?

I don't use any of these commands, so I'm really not qualified to talk
about changing them :(.

>> work.cc workspace::has_changes
>>     should return true, not abort
>
> This is only used by kill_rev_locally to apply former changes back to
> the workspace parent. Generally it should not hurt if it returns true,
> since the only thing what will be done afterwards is that the
> workspace' revision is overwritten with the previous changeset - so
> any missing file will be later alerted in a subsequent command
> anyways. 

Or that operation could restore the missing file.

> However, if has_changes will later be introduced to other things (my
> "plan" was to also use it for commit), this change will certainly
> make problems.

Right. Which means it needs an option saying what action to take for
missing files.

-- 
-- Stephe