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 enforceor 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 | [EMAIL PROTECTED] | 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
_______________________________________________ Monotone-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-devel
