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

[Thomas Keller]

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. IMHO it should 
just plainly list the contents of _MTN/revision and skip / empty the 
fileid stanza for missing files. But yes, it should not abort. To 
actually get an overview what files are missing in a workspace, we have 
automate inventory.

> 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?

> CMD(changed)
>
>     'missing' files should show as deleted; should not abort

I'm still undecided if - here and in the other cases -"missing" should 
be the equivalent of "deleted"...

> CMD(merge_into_workspace)
>
>     'missing' files were probably removed by the user to resolve
>     conflicts. On the other hand, it might be important to see any
>     conflicts. So this command probably needs a user flag to enforce
>     or suppress the check on missing files. 
>
>     Or maybe it should just be the same as 'update'

This is one of the write operations where I really want to stick with it.

> 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?

> 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. 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.

> workspace::maybe_update_inodeprints
>
>     might make sense to abort; depends on where it is called from. If
>     it doesn't abort, the loop that updates the inodeprints has to
>     be improved to handle missing files.

I guess this is the root cause for f.e. automate get_current_revision to 
fail if there are missing files. If we handle this one, we should 
(theoretically) have "fixed" a whole bunch of workspace commands.

Thomas.

--
GPG-Key 0x160D1092 | address@hidden | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en

signature.asc
Description: OpenPGP digital signature