commit philosophy

Philosophical question about commits.

* Suppose I have a working copy at revision 3, and the head revision
  on the repository is 10.

* Suppose a file "foo/bar/baz.c" has a local change. So lazily, I
  type 'svn ci foo/bar'.

* However, suppose that baz.c has a sibling subdir, "foo/bar/bop/", at
  revision 5.

Here's the issue: should my commit cause revision 5 of foo/bar/bop/ to
be merged into the head revision? Or should it do *nothing* but
create a new revision of baz.c?

Remember, I committed the whole foo/bar/ directory. Does that mean
that when I'm done committing, foo/bar/ in the head revision should
look *exactly* like my working copy's foo/bar/, even if that means
effectively "retrograding" the node-rev-ids in revision 11?

(I ask this question, because I just realized that we're *not* doing
that right now. Our commit-driver, crawl_local_mods, won't call
replace_dir(5, foo/bar/bop/) unless it specifically finds an add,
delete, or local file mod somewhere inside foo/bar/bop/. Is this
wrong?)
Received on Sat Oct 21 14:36:26 2006