[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

commit philosophy

From: Ben Collins-Sussman <sussman_at_newton.ch.collab.net>
Date: 2001-03-29 15:39:12 CEST

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

This is an archived mail posted to the Subversion Dev mailing list.