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

[Thomas Keller]

Stephen Leake schrieb:
> 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!

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

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

This was not about changing, but dropping 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.

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