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

Re: "svnlook changed" different for WC->URL and URL->URL copy

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: 2005-05-31 19:43:51 CEST

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: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue May 31 19:48:47 2005

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