monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Monotone-devel] Re: .mt-ignore and .cvsignore files


From: Bruno Hertz
Subject: [Monotone-devel] Re: .mt-ignore and .cvsignore files
Date: Fri, 13 May 2005 01:04:43 +0200
User-agent: Gnus/5.110003 (No Gnus v0.3) Emacs/22.0.50 (gnu/linux)

Emile Snyder <address@hidden> writes:

> Well, the fact that a revision refers to the state of a tree of files
> makes it, in my mind at least, about versioning trees of files.  I'm not
> saying that you can't use it for what you wish, just that it's not a
> perfect impedance match.

Well, what I gather from the manifest is that it's not a tree of
files, it's just a set of revisioned content with (pretty arbitrary)
pathnames attached to it. The only point where the 'tree' paradigm
really enters the picture is with MT, which is supposed to sit on the
'root' of the working copy. But that seems to be all of it. Also, the
monotone model is afaik not the least concerned with directories.

>
> 90% of the time when I'm using it for version control in a software
> project I want it to operate recursively, and I have non-sparse tree of
> files to control.  When I imagine sparse tree use cases, I immediately
> think of lots of cases where I'll want nested MT directories... ie.
> /home/esnyder under control for config files, /home/esnyder/writing
> under control for some top level files,
> /home/esnyder/writing/project-foo under control as project-foo, etc..
>
> In my "normal" case, the file ignore stuff is used to keep a version
> control tool from bugging me about "useless" files; things that I don't
> care if I lose.  But in the sparse tree case, it's getting used to say
> "for *this project* please ignore these files," not that they're
> inherently unimportant.
>
> I'm not trying to argue that, if possible, monotone shouldn't support
> this sort of sparse tree use.  But I would argue that it shouldn't make
> the current dominant usages less convenient or safe in order to support
> it.

Sure.

>
>>From where I stand the recursiveness looks like a strength, not a
> limitation ;)  But would be even stronger if the ignores applied
> (efficiently) to subdirectories as well as files.

I never said recursiveness should be prohibited. But as of now, the
opposite applies, i.e. one can't prevent recursiveness, which is a
serious and unnecessary limitation.

Another issue discussed in a different thread was which should be the
default, and what the option. But in that regard I've made my points
and hence regard the matter as settled.

Regards, Bruno.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]