Re: [Monotone-devel] What are rosters?

[Nathaniel Smith]

On Tue, Aug 21, 2007 at 11:31:30AM +1000, William Uther wrote:
> There would have to be a new command that said "Resurrect file X from  
> revision Y".  It would error out if file X is already in the current  
> revision (and tell you to use rename instead).  It would act a little  
> like 'merge_into_dir' if the file never existed in any child ancestor  
> of the current revision, in that it would add it to the current rev.   
> It would otherwise resurrect the file - i.e. add the node back to the  
> roster with the contents from that revision.
> 
> Hrm.  What does this mean for history tracking?
> 
> If we just do what I said above, then we'd lose history.  We'd also  
> need to make sure that the revision we resurrect the node from is a  
> parent of the new revision generated.  This might be best done by  
> cloning merge_into_dir quite closely, and so the resurrect command  
> would actually commit its own revision rather than being a workspace  
> command.  This is probably ok as you can use revert to get back a  
> file that you've deleted but not committed yet.

This reasoning seems wrong.  If you can represent something in
history, then you can represent it in the workspace, and vice-versa.
Recall that history is fundamentally just a bunch of revision texts,
*not* rosters -- rosters are a fancy cache for the data contained in
the revision texts.  And the workspace has this file called
_MTN/revision :-).

I like workspace commands more than direct-to-db commands myself --
more chance to inspect things and make sure they're right.  Actually
I'd rather have merge_into_dir become a workspace command, now that we
have some workspace merge stuff...

-- Nathaniel

-- 
The Universe may  /  Be as large as they say
But it wouldn't be missed  /  If it didn't exist.
  -- Piet Hein