Re: M-x big-picture

Jim Blandy wrote:

> Branko =?ISO-8859-2?Q?=C8ibej?= <brane@xbc.nu> writes:
>
>>> 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.
>
>
> You're completely lost. :)
>
> Subversion doesn't branch. Instead, you make a copy of your entire
> source tree, and work there.

I see. I think I see. I sort of assumed we're using the same sort of
revision numbering as RCS/CVS, which encode the branch structure in the
revision numbers.

How are we going to encode the branch structure, then? I can imagine
properties on the root dir linking the nodes into a tree, but that won't
work deeper down in in the tree. This would make "svn log" very
inefficient, wouldn't it?

I'm trying to wrap my head around this idea, see what we gain ... O.K.,
copies will be a bit faster, although not much (in fact, we don't gain
for file copies). But it occurs to me that we'll be throwing away
information that would be useful for things like "svn log", tools like
the revision tree browser, etc.

On the other hand, it occurs to me that we could have used a simpler
revision numbering scheme if we only use ti to encode successor/ancestor
relationships. In the current scheme, the node and revision numbers can
become really long, and in practice they probably will, too. (Unlike the
branch structure in the configuration management sense, which has to be
simple enough for users to understand, creating a successor node won't
have a visible impact on the complexity of the repository. But it will
keep on adding pairs of numbers to our node IDs.)

F'r instance: Each node is identified by a node number and a node
revision number, like so:

        node.revision

The first revision of a node can have an ancestor (if it was branched or
copied), which we indicate by sticking the ancestor's ID onto the node's
ID, thusly:

       node.1<-ancestor-node.ancestor-revisoin

To find the node's successors, we have to add index entries (without
data!) for each successor, in the following manner:

       node.revision->first-successor
       node.revision->second-successor

We don't have to show the successors' revision numbers, they're always
1. The nice bit is that we can still do range queries in the index to
find all ancestors of a revision, and the index entries have a know
maximum size.

The example in the "structure" file would look look like this:

       13.1
       13.2
       13.2->15
       13.2->16
       13.3
       13.4
       13.4->17
       14.1
       14.2
       14.3
       15.1<-13.2
       15.2
       15.3
       16.1<-13.2
       16.2
       16.3
       16.4
       17.1<-13.4
       17.2

With a bit of generalization we could record a complete DAG in such an
index, not just a tree

Hmm. Don't mind me, just thinking out loud ...

-- 
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/