Re: [Monotone-devel] Questions pertaining Eclipse Integration

[Timothy Brownawell]

On Sat, 2006-10-28 at 21:59 +0200, Ulf Ochsenfahrt wrote:
> > - How can I add a directory non-recursively?
> 
> Richard:
> > I'm not sure you can.  If you want to add specific files in a
> > directory, just add them, the directory itself will be added
> > automagically if needed.
> 
> Timothy:
> > ...why doesn't add take --depth? Anyway, aside from changing that, you
> > can probably just add the directory and then drop all its children.
> 
> It would be nice to have a --non-recursive/--no-depth option, if the 
> current is to stay the default. (Or conversely, add a --depth option and 
> change the default to not add files recursively.)

I was thinking probably keep the same default, but add --depth so you
can do --depth=0 to be non-recursive. (Why do we have --depth instead of
a recursive/non-recursive flag? Does anyone actually use the extra
flexibility?)

> Adding the directory and then dropping the children isn't really an 
> option. It invites quite a number of problems. What if a child is 
> deleted in the meantime? What if the subtree is huge? 

Yeah, these would make it annoying. But at present I think they're all
that's available.

> Also, you'd have 
> to recursively go through all subdirectories and first remove all their 
> children. (I just checked, mtn drop returns an error message for a 
> non-empty directory.)

'mtn drop -R' is recursive. (hey, we do have a --recursive option. Can
we add a --non-recursive and kill --depth?)

> > - How can I suppress the automatic commit message dialog and get an 
> > error instead if no message was given on the command line?
> 
> --rcfile=- is a useable option, but when used with automate stdio, you'd 
> have to know all information with regard to the rcfile before the mtn 
> subprocess is started, or you have to start a new mtn subprocess, which 
> severely limits its usability for frontend integration (e.g. Eclipse).
> 
> It would be nice to have a global --non-interactive option, that makes 
> mtn always return an error instead of asking on the console/starting an 
> editor process. Alternatively, it might implicitly set this option, if 
> the stdin/stdout isn't a console.

I'm not sure how well this would work, since most interactive stuff is
done by hooks (IIRC the only exception is prompting for passwords). And
user-defined hooks might not choose to respect this option.

-- 
Timothy

Free (experimental) public monotone hosting: http://mtn-host.prjek.net