Julian Foad <julianf...@btopenworld.com> writes: > Philip Martin <philip.mar...@wandisco.com> wrote: >> http://subversion.tigris.org/issues/show_bug.cgi?id=4042 > [...] Should we support that in 1.7? Or should we simply have the >> client refuse to commit incomplete nodes. Most incomplete nodes >> occur after an interrupted update, but wc could have incomplete >> working nodes resulting from a wc-wc copy. > > I think we should start refusing to commit changes to or in an > incomplete' directory, in order to keep things simple. I don't see a > practical reason why such a commit should be supported, only the > eternal desire to keep backward-compatibility. Back-compat is very > important to me in general, but here it appears to me that we have an > example of a behaviour which isn't wanted and merely happened to > exist. (I mean the ability to commit a dir while it's marked > incomplete' is not important, I don't mean nobody ever finds a use for > it.) Please speak up if I'm wrong about that.
What does refusing to commit incomplete directories mean. Given: $ svn st wc ! wc/A/B M wc/A/B/C/f !M wc/X/Y M wc/X/B/C/f M wc/P/f Do these fail due to incomplete: $ svn ci wc/A/B/C/f # explict inside incomplete $ svn ci wc/A # implicit inside incomplete $ svn ci wc/X # implicit beside incomplete $ svn ci wc/P # incomplete in some other part of wc -- uberSVN: Apache Subversion Made Easy http://www.uberSVN.com
