>> Okay. Now suppose someone does:
>>
>> svn co -r 5 dirname
>> cd dirname
>> svn rm -f alpha
>> svn ci
>> svn update -r 5 dirname
>>
>> After the "svn ci", what is the wc version of "dirname"?
> It would be "current". Before a "svn ci ." can occur, the directory
> must be up to date since you're removing an entry from the
> directory. So... if 5 is "current", then the ci proceeds. If it
> isn't current, then the ci fails with an "out of date."
I think that's just not so. According to libsvn_fs/structure, we are
able to merge in a removal of a file with other unrelated changes to
the directory. (Under "merging" rules, the case is: A and B are both
directories, E exists in ANCESTOR but has been deleted from A, E
exists in B and refers to the same node revision. The result is "Omit
E from the merged tree.")
So the problem remains. Even if the directory has to be up to date at
the beginning of the commit operation, someone could sneak in an
unrelated directory operation before the commit transaction completes,
and according to our merge rules we do not throw a conflict.
>> As a second and possibly harder issue, if I "svn cp dir1 dir2",
>> what goes in the SVN files of dir2, which doesn't yet exist in the
>> repository? If I commit immediately, how does the client figure
>> out to report a single directory copy with no new files? What if
>> I'm a putz and I cd somewhere into dir2 and try to commit there?
> In the above scenario, what is the state of dir1 and dir2? Which are
> in the repository, and which have not (yet) been comitted. From your
> continued prose, it sounds like *both* dir1 and dir2 are brand new.
Er, no, sorry. "dir1" was supposed to be an existing directory and
"dir2" was supposed to be newly created by the svn cp command. I know
what editing operation is supposed to result, but I have to wonder if
our working copy design is sufficient to make it actually happen.
Received on Sat Oct 21 14:36:27 2006