Re: [Monotone-devel] Re: comments on net.venge.monotone.workspace-merge.migration

[Nathaniel Smith]

On Tue, Aug 22, 2006 at 09:10:26AM +0200, Marcel van der Boom wrote:
> My (our) usecases are twofold:
> 
> 1. reading _MTN/revision (automate get_base_revision is fine for that)
> 2. writing to _MTN/revision.
> 
> The second is the thing i use a lot. For our customers i install all  
> products in a mtn working directory (mostly on our servers, but  
> sometimes on location). This number grows on a weekly basis. (total  
> is like 150 atm i think)
> Development continues as usual, while quite a few of the customer  
> installs have their own changes.
> 
> I'm not married to writing to _MTN/revision but what i would like to  
> be able to do is to set an arbitrary revid as the base revision to  
> get information about what the workspace at the install is like in  
> relation to that revision. Putting that revid in the revision file  
> and using mtn status / mtn diff --external is the usual start sequence.
> 
> This currently allows me to quickly put a number of revisions in the  
> _MTN/revision file and get a feel where the workspace is at and what  
> needs to be done to upgrade/downgrade it to some revision we want.  
> Recently, the mtn pluck command has been added to the toolset for  
> these excercises :-)

Hrm.  That's a... creative way of doing things :-).  I don't think we
can support this particular mechanism in any useful way (and in fact,
it's already pretty sketchy -- don't you run into problems when there
have been any adds/removes/renames?).

That just means we should have a cleaner way to support this use case,
though.  To start with, what's wrong with 'diff -r <revision>'?  Would
it be useful to have 'status -r <revision>'?

-- Nathaniel

-- 
So let us espouse a less contested notion of truth and falsehood, even
if it is philosophically debatable (if we listen to philosophers, we
must debate everything, and there would be no end to the discussion).
  -- Serendipities, Umberto Eco