Re: FS copy model

Greg Stein wrote:

> To answer my own question, and state my desired outcome:
>
> *) when a copy is made, we create a new branch (e.g. create 73.4.1.1)

I think we most emphatically do /not/ want to create a new branch for a
copy; the semantics are wrong. If we start creating branches for every
copy, the version tree (as implicit in the structure of the node ID)
will no longer correspond to real branches in the repository.

A copy must either stay on the same branch, or create a new node (with a
backlink to its origin as a property).

Personally I think creating a new node is best, although we don't
(right now) have any way to represent the ancestry link (it's an
immutable non-historic property, after all).

Well ... except if we don't care about what the node ID structure says,
and are only interested about branches on the repository root?

Hmm. In that case, I'd still prefer that the copy itself touches only
the directory, and we branch off the file only when changes are actually
made to it. That would be consistent with the way we (will) implement
tags and "real" branches.

> Potential funky feature: the two props that are assigned to 73.4.1.1 would
> be carried into 73.4.1.2 unless something deleted them in that delta. To
> avoid this, the copy information could be stored as something other than a
> property (e.g. an intrinsic part of the node branch mechanism).

If you really need more information than is stored in the directory
entry list, you can put it in the directory's properties.

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