> From: Branko Cibej [mailto:brane@xbc.nu]
>
> I really meant to reply sooner ...
>
> Karl Fogel wrote:
>
> >Branko Èibej <brane@xbc.nu> writes:
> >
> Coming, coming ...
>
[.....]
> > Solution B:
> > ===========
> > Reference nodes.
> >
> >
> >
> [snip stuff about symlinks]
>
[... lots more snipping]
> This is basically it, but I'll expand a bit. I think we'd need two
kinds
> of references -- local (intra-repository) and global
(inter-repository).
> Whether those are implemented using the same node type isn't important
> now. Global refs aren't necessary for 1.0, and are a huge problem by
> themselves, so I'll ignore them.
>
> In the FS, a local reference node would store the FS path (not the
URL!)
> of the target and (optionally) a revision number. If the rev number is
> absent, the path refers to HEAD. Conflict resolution for ref nodes is
> the same as for files.
>
Indeed, I'd point out here that a local reference node that's tied to a
revision number should be stored thusly:
TargetNodeID.TargetCopyID.TargetTxnID TargetPATH
TargetPATH is only for UI helping purposes, the use of a
TargetNodeID.TargetCopyID.TargetTxnID is a data retrieval optimization.
If you hadn't noticed this yet, this is the hard link that people have
been wanting. :) It even behaves sanely in the face of copies/branches.
> On the client side, some commands have to be aware of ref nodes, and
> there are usually two choices for the semantics: e.g., does "svn copy"
> copy the reference or the target? The simplest answer is to treat
> references like unix treats symlinks.
>
+1
> > One unanswered question is, how does a client create a
> > reference? Make a text file with the reference value in it,
and
> > then use a special flag at add time?
> >
> > $ svn add --reference foo
> >
> > Or overload symlinks? I dunno. There are probably multiple
> > acceptable solutions for the client-side user interface.
> >
> >
> You can't overload symlinks, because they aren't available everywhere.
> What you need is a new command:
>
> svn link [-r REVISION] TARGET SOURCE
>
> where both SOURCE and TARGET can be either a WC path or an URL (into
the
> same repository), and revision refers to TARGET, of course. If SOURCE
is
> an URL, this caises an implicit commit of the link. If SOURCE already
> exists and is a reference, this command would modify the reference
itself.
>
> There's also the question about how you remove a reference node. You
> have two choices:
>
> * "svn rm" on a reference always removes _just_ the reference, not
> the target
> * "svn unlink" removes only references; "svn rm" removes only
> targets, but requires --force
>
> I'm sort of leaning towards the first solution.
>
Let's continue the symbolic link metaphor, because that's what we indeed
have here. In that spirit the first solution definitely makes sense.
>
> Come to think of it, "svn link -r" would be sort of like a tag, too
...
>
More so than "svn copy /trunk/svn /tags/svn/milestone-X" is that's for
sure. In fact, I like this much better for doing tags. I don't suppose
this means anyone will let us rename "svn copy" to be "svn branch" now
that we can add a "svn tag TAGPATH -r SOURCEPATH" command. ;)
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri May 17 08:28:32 2002