On Fri, 2011-02-11, Philip Martin wrote: > Julian Foad <julian.f...@wandisco.com> writes: > > > On Thu, 2011-02-10, Philip Martin wrote: > >> There has been a behaviour change reverting copied directories between > >> 1.6 and the current 1.7. > >> > >> In 1.7 the depth of the revert must match the depth of the copy, so if > >> the directory only has files it can be reverted using depth=files, if > >> the directory has empty immediate subdirs it can be reverted using > >> depth=immediates, and if the directory has subdirs with children > >> depth=infinity must be used. That seems straightforward. > >> > >> In 1.6 it is a bit different, the revert depth doesn't need to be as > >> deep as the copy. A copied directory that only contains files can be > >> reverted using depth=empty, and a directory that has subdirs containing > >> only files can be reverted using depth=immediates. > > > > When you say "can be reverted", I assume you mean that 1.6 removes the > > directory and all its contents, the same as if depth=infinity had been > > specified. (I can't think of any sane behaviour that would affect less > > than the actual depth when reverting a copy.) > > depth=empty locks the dir and allows revert if there are no subdirs, > depth=immediates locks immediate subdirs and allows revert if there are > no sub-subdirs. > > > If so, I'd say that's an off-by-one bug in 1.6's depth comparison, and > > the 1.7 behaviour is correct. > > 1.6 just uses the locks rather than a depth comparison, and
OK, I get it now. > that does > make 1.6 look like the one that is wrong. I don't know if it's worth trying to fix it in 1.6 - it doesn't seem like a very serious bug. It's good that it's already working right in 1.7. (A side note. A depth-limited revert of a copy may be an unimportant use case at the moment, but it's worth being careful to get the depth support right. In future, we will have better support for renames. Then it should be possible to revert a renamed directory, specifying an operational depth less than its depth on disk, in order to undo the rename without having to revert all other changes inside it. The depth support in that case will not be simply a go/no-go check, but will control the extent of the reversion. It might or might not share code with the 'revert a copy' case.) - Julian
