I understand what you're talking about. Two comments:
- I believe that over ra_local and ra_svn, such not-really-mixed-rev
working copies would still wind up doing what you would expect
because libsvn_fs checks to see if a copy would result in no real
change, and if so, does nothing. ra_dav has a problem here, in
that mod_dav flatly hijacks the ability for a copy to overwrite
an existing object. (There's an issue in our tracker that covers
this.)
- The full "fix" for what you're talking about likely involves the
Subversion client code doing all the work that the Subversion
server code does right now to determine if a copy would be a
no-op. Trust me -- replicating that logic is a bad idea (for
performance).
kfogel@collab.net writes:
> "C. Michael Pilato" <cmpilato@collab.net> writes:
> > Karl, it looks like you've already nailed the probable cause --
> > mixed-revision working copy as the source of the copy. While doing a
> > WC->URL copy, every time a file or directory's revision differs from
> > that of its parent, that object is transmitted as its own distinct
> > add-with-history operation. This is the correct behavior for WC->URL
> > copies, though -- not a bug.
>
> Well, not always, maybe? There are "real" revision differences and
> "fake" ones. For example, suppose I do this:
>
> $ svn co http://blahblahblah.com/repos/myproj/trunk/ myproj
> [...]
> Checked out revision 1729.
> $ cd myproj
> $ svn up -r 1728 foo.c
> $
>
> Let us assume that foo.c did not change in r1729 -- in fact, say foo.c
> hasn't changed since r1. If I now do
>
> $ svn cp -m "Make branch." \
> http://blahblahblah.com/repos/myproj/trunk/ \
> http://blahblahblah.com/repos/myproj/branches/newbranch/
> Committed revision 1730.
> $
>
> ...would we expect to see exactly one path in the 'svn log -v' output
> for r1730, or two -- one add-with-history to create the branch from
> r1729 of trunk, and another to splice foo.c@r1728 into that branch?
>
> I'm not doing a very good job of articulating what I mean by a truly
> mixed-revision working copy versus a fake one, but I think you see
> what I mean. In a fake one, those cases where an object's revision
> differs from that of its parent are spurious: were you to update the
> object to its parent's revision, the node revision identity of the
> object wouldn't actually change.
>
> -Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue May 31 19:45:56 2005