> From: Branko Cibej [mailto:email@example.com]
> I really meant to reply sooner ...
> Karl Fogel wrote:
> >Branko ╚ibej <firstname.lastname@example.org> 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
> of references -- local (intra-repository) and global
> 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
> 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:
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.
> > One unanswered question is, how does a client create a
> > reference? Make a text file with the reference value in it,
> > 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
> same repository), and revision refers to TARGET, of course. If SOURCE
> an URL, this caises an implicit commit of the link. If SOURCE already
> exists and is a reference, this command would modify the reference
> 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. ;)
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Fri May 17 08:28:32 2002