Re: M-x big-picture

Greg Hudson wrote:

>> O.K., that's all clear as long as the source is a file. If it's a
>> directory, we actually want to copy the whole tree. So it seems to
>> me that we have to create copies of its children when they change,
>> but I've seen discussions about creating branches instead.
>
>
> I think we will wind up creating branches instead.
>
> The purpose of a copy node is to preserve the information about a
> copy. (Not that we have a way for clients to get at that information
> yet.)

We will, though.

> It remains the case that two different files (foo/xxx and
> bar/xxx, if foo was copied to bar) might live in the same node. The
> information about what happened should still be there if you look hard
> enough.

But this doesn't make sense to me at all. If I want a new branch, I'll
use "svn branch". Copy should never create new branches, it's just
semantically wrong. Either that, or I'm completely lost.

(I would even argue that copying a revision that's not on the main
branch should create a copy on the same branch level; i.e., copying node
revision "1.2.3.4" should create a new node with "2.1.1.1" as its only
revision. "branch" and "merge" commands should be the only way to create
new branches on a node.)

It would be quite easy to do lazy directory tree copies. Like this:

a) "svn copy" of a directory creates a new "copy" node, no more.

b) The first change on the copy creates a "dir"-type successor, *and*
copies of all of it's children.

That's not completely O(1), but it's a lazy copy and the recursion is
automagic and on-demand. This shouldn't be much slower than branching
off the child nodes; creating a "copy" node is fast and simple since it
has no extra baggage to keep synchronised. And IMHO it's acceptable to
have tree copies be a bit worse than constant-time.

-- 
Brane �ibej
    home:   <brane_at_xbc.nu>             http://www.xbc.nu/brane/
    work:   <branko.cibej_at_hermes.si>   http://www.hermes-softlab.com/
     ACM:   <brane_at_acm.org>            http://www.acm.org/