Stephen Leake schrieb:
Thomas Keller <[EMAIL PROTECTED]> 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 abortNo, get_current_revision should only list those files as deleted whichhave 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!
Still undecided about that - what if the file got accidently deleted? Sure, its recoverable via revert and one has to look cleanly onto the changeset one wants to commit anyways to avoid such accidential deleted files, but I'm at least completly satisfied with mtn drop --missing ...
cmd_diff_log.cc prepare_diff 'missing' files should be shown as 'only in other'; should not abortEven 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 whyare 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.
In newer mtn versions mtn drop also means fs drop (this was changed when the --execute option was removed and the --bookkeep-only option was added).
There are systems with inotify support and similar techniques which could be told to do the required mtn action after a filesystem action and I'd find such a thing highly appealing, but I'd always want to opt-in for such a thing and never have to opt-out.
CMD(get_roster) 'missing' files should show as deleted; should not abortI 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 :(.
This was not about changing, but dropping them ;)
work.cc workspace::has_changes should return true, not abortThis 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 commandanyways.Or that operation could restore the missing file.
...which would mangle functionality from revert into kill_rev_locally. Anyways, I have no plans nor time to touch this code anytime soon, so somebody else would have to deal with that.
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
