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

[Emile Snyder]

On Thu, 2005-05-12 at 13:46, Bruno Hertz wrote:
> Emile Snyder <address@hidden> writes:
> 
> > On Thu, 2005-05-12 at 06:39, Bruno Hertz wrote:
> >> What we are talking about here is situations where files under
> >> revision control are sparse in a directory tree. As an example,
> >> consider putting your home directory under revision control for files
> >> like ~/.profile or ~/.emacs. In such a scenario, commands like list
> >
> > Given that monotone is about versioning trees of files, this seems kinda
> > like twisting it out of it's groove to me.  Is there a problem with just
> > having a myconfigs project, and symlinking; eg. ~/.emacs to
> > ~/myconfigs-workingdir/.emacs ?  Seems cleaner.
> 
> Well, putting /etc under revision control was a recent svk usage
> example in a Debian news letter, and it makes sense. The same applies
> for scenarios like various configuration files in home directories and
> dot subdirs, like .monotone/ or whatever.

Do you want all of /etc in one module/branch, or piecemeal?  If so, this
doesn't seem much like wanting /home/myuser under version control, but
with just some .config files checked in; more like the usual case of a
tree of files that you want (most of) under VC.

> And no, I think it's not a good option to 'set up' your home dir for
> revision control, symlinking all kinds of stuff from various

I can understand the reluctance to muck around like this.

> locations. That's the neatness of monotone after all, that it's
> actually not concerned with directory trees. It's concerned with
> files, sitting somewhere in a tree.
> 
> What makes it look like being concerned with trees is the UI only,
> e.g. the recursiveness we've been talking about, but this is actually
> just an interpretation, and limitation, of it's capabilities.

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.

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.

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

thanks,
-emile

> Regards, Bruno.
> 
> 
> 
> 
> _______________________________________________
> Monotone-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/monotone-devel

+----------------------------------------------------------------------
"When the revolution comes, we'll need a longer wall." -- Tom De Mulder 
+----------------------------------------------------------------------