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

[Nathaniel Smith]

>===== 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!

Random comments:

  - Partial updates: These don't just create a fork; they create a completely
    independent new root node in your branch.  (Ignoring the unlikely case
    where you coincidentally recreate some independently committed version.)
    I can't think of a case where breaking history like this would actually
    be desireable;for that matter, I can't really think of a case where a
    partial update is desireable.  And if someone does encounter such a case,
    I feel pretty comfortable telling them to do
       $ cp -r working-dir scratch1; cp -r working-dir scratch2
       $ (cd scratch2; monotone update)
       $ diff -rN scratch1/subdir scratch2/subdir | (cd working-dir; patch 
-p1)
    Note that this does a proper three-way merge, if you commit it it will
    create a version that merges relatively easily with head, etc.  So I
    advocate not allowing partial updates at all.  (Of course, if in the
    future someone comes up with some really clever way to make them work
    nicely, we can revisit this...)

  - Default '.' restriction: I sort of expect to be shouted down about this,
    but I'll try one more time.  IIUC, at present with restrictions, if
    you're in a subdirectory, all commands are implicitly restricted to that
    subdirectory.  This seems logical, but I think it is actually bad.  The
    reasoning is this: for CVS, this makes sense, because in CVS you are
    versioning files and directories.  Every subdirectory of a working
    copy is itself a complete working copy; it doesn't even make sense to
    speak of "the working copy".  Monotone is different, though; in Monotone
    the fundamental versioned unit is a tree.  In Monotone, you always have
    a unique root directory that everything works with respect to; in
    Monotone, you always checkout and commit complete tree states.  (Even if
    you're using restrictions on a commit, conceptually this doesn't mean
    you're not committing masked-out files -- it means that when you re-commit
    those files you leave out your local changes.)

    Given all this, I think the Monotone by default should always work over
    the complete working directory.  This is a sharp gotcha for people coming
    over from CVS, but for one thing, it's pretty easy to document as such,
    and whole-tree commits are already something former CVS users have to
    make significant and explicit adjustments for.  More importantly IMHO,
    it gives the correct behavior in the long run; you only switch to Monotone
    once (at most!), but you use it for a lot longer.

    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 .
    Whereas with the current behavior, to get a diff of the current directory,
    I say
      $ monotone diff
    and to get a full version diff, I say
      $ monotone diff ../../../..
    (except the actual number of ..'s is different each time, and it always
    takes me three tries to figure out how many to type, so I instead spend
    some time cd'ing around the tree to get into the root directory, and
    by then I've lost the context of where I was working before...)

    I'd rather type the '.' and explicitly express my intention.

  - Exclusions: I would support an actual --exclude syntax; I'm pretty sure
    my main use case for restrictions on commits, say, would be to exclude
    just one or two files that I had to insert some stupid hack into, like
    a Makefile where I forcibly overrode some configure test or something,
    and I'd much rather be able to say
      $ monotone commit --exclude Makefile
    than
      $ monotone commit `find . -type f -a ! -path ./Makefile`
    (esp. since I had to refer to the find manpage twice to get that right,
    and it can't be made to work on really big trees, because it will overflow
    the maximum command line size, and xargs doesn't work for commit.)

    A --exclude-re switch or similar might be kinda cool too, but maybe that's
    going too far :-).

All that said, thanks a lot for all the work on this, it's a long-awaited 
feature!

Cheers,
-- Nathaniel