Re: Branching with missing revisions

On Wed, 2004-08-11 at 13:19, Kevin Ballard wrote:

> There's definitely *some* bug. I just did a test with a local file:///
> repo (once again subversion 1.1.0 rc 2) and I saw some weird behaviour.
> Here's what I saw.

Nope, no bug here. All explainable and expected.

In r2, you have 'foo' and 'bar' in trunk/.
In r3, you create trunk/foobar/, and move foo into it.

Keep in mind that if you were to run 'svn log -v -r3' to see the changed
paths in r3, you'd see something like this:

   D /trunk/foo
   A /trunk/foobar
   A /trunk/foobar/foo (copied from r2, /trunk/foo)

In other words, svn doesn't have "true" moves; it just copies and
deletes.

So, look at your mixed-rev working copy:

>
> kevin:~/Dev/TestRepo/trunk% svn status -v
> 2 2 kevin .
> 2 2 kevin bar
> 3 3 kevin foobar
> 3 3 kevin foobar/foo

You've got r2 of /trunk, and r3 of /trunk/foobar.

> kevin:~/Dev/TestRepo/trunk% svn copy .
> file:///Users/kevin/Dev/svn/TestRepo/branches/abranch
>
> Committed revision 4.

So you've built a transaction on the server. What does it look like?

* you started out with a copy of r2 of /trunk:

         /trunk
         /trunk/foo
         /trunk/bar

* then you added in a copy of r3 of /trunk/foobar:

         /trunk
         /trunk/foo
         /trunk/bar
         /trunk/foobar
         /trunk/foobar/foo

The whole 'move' idea never happened. The 'svn cp Wc URL' command just
mindlessly constructs a transaction based on the mixed-revs in your WC,
it's not replaying commits or anything like that.

> kevin:~/Dev/TestRepo/trunk% svn switch
> file:///Users/kevin/Dev/svn/TestRepo/branches/abranch
> A foo

So, sure enough, when you 'update' your working copy to the new tree, it
adds foo back in. That's the difference between your working copy and
the new server-tree.

There's a moral to this story: the book is a bit misleading. It gives
the impression that 'svn cp . URL' will create an *exact image* of your
working copy in the repository, that it's somehow doing a 'cp -R' over
the network. That's not true. Technically, it builds tree that is a
reflection of your working-copy's mixed revisions. But working copies
are flexible: you can have revision N of a directory, but have extra
entries, or missing entries. The .svn/entries file keeps track of those
discrepancies, so that users have the flexibility of mixing and matching
revs. Working copies have 'imperfect' revisions of directories. So
when "copying mixed revs" from working-copy to server, you may end up
with a server tree that's slightly different than exactly what's in your
working copy.

When the book recommends 'svn cp WC URL' as way of creating a
mixed-revision tag, it's really operating under two assumptions:

  1. you start out with a working copy all at one revision (i.e. running
'svn up' first)

  2. you selectively backdate or foredate only single *files*, not
directories. Messing with directory versions can lead to the skew
between what you see and what you get. Messing with file versions won't
do that.

So I think I need to make that part of chapter 4 clearer. Thanks for
pointing this out.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Aug 12 23:19:47 2004