[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Re: svn commit: rev 1957 - trunk/subversion/include trunk/subversion/libsvn_wc

From: Bill Tutt <rassilon_at_lyra.org>
Date: 2002-05-17 08:26:07 CEST

> 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
> 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:
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.
> > 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:
> 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: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri May 17 08:28:32 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.