monotone-devel
[Top][All Lists]
Advanced

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

[Monotone-devel] Re: [long] subdirectory restrictions


From: graydon hoare
Subject: [Monotone-devel] Re: [long] subdirectory restrictions
Date: Tue, 21 Sep 2004 07:16:06 -0400
User-agent: Opera M2/7.53 (Linux, build 737)

On Mon, 20 Sep 2004 23:39:08 -0700, Nathaniel Smith <address@hidden> wrote:

===== Original Message From Derek Scherger <address@hidden> =====
I'm happy to report that I finally have restricted/subdirectory
operations essentially working in the code on the restrictions branch.

Yay!

seconded! this is great news derek, thanks.

  - Partial updates: These don't just create a fork; they create a completely
    independent new root node in your branch.

yeah, these are actually very dangerous since they merge so well; I'm happy
just leaving this disabled for a while.

    There's also the standard pragmatic test, that asks which behavior is
    easier to emulate given the other... in my proposal, to get a full
    version diff, I say
      $ monotone diff
    and to get a diff of the current directory, I say
      $ monotone diff .

I do somewhat like the sound of this better. and honestly, I often do a diff
to see what I'm about to commit, so having the system *accidentally* tell me
that there's stuff I forgot about (which I'm going to commit) one directory
over is a virtue in my mind.

that said, the other "standard pragmatic test" is to ask a statistically
meaningful group of users which feels better. anyone else have a preference?

    and I'd much rather be able to say
      $ monotone commit --exclude Makefile
    than
      $ monotone commit `find . -type f -a ! -path ./Makefile`

eh, I don't know, "monotone commit `find | grep -v '^Makefile'`" is how
I'd compose it, and I don't feel like I'd be hurting myself much by having
to say so. but then, maybe bash scar tissue shouldn't be a prerequisite
for using new tools. I don't know.

you're right that --exclude can exist independently of --include, though;
and I think I'm comfortable with this notion of returning positional args
to their conventional role of meaning "included filenames". all well and
good. on --exclude, then, anyone else have a preference?

-graydon




reply via email to

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