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

Re: Ev2 symlinks

From: Daniel Shahaf <danielsh_at_elego.de>
Date: Fri, 28 Jun 2013 03:01:53 +0300

Branko Čibej wrote on Thu, Jun 27, 2013 at 21:32:31 +0200:
> On 27.06.2013 21:16, Greg Stein wrote:
> > On IRC, Branko noted:
> > on the subject of ev2 api, i'm wondering if add_symlink and
> > alter_symlink should really be there. it looks like special-casing on
> > one type of special node
> >
> >
> > There is *only* one type of special node. There are no plans for any
> > other type of special node.
>
> Yes, there are. And not only in my head, either. :)
> I just haven't got around to starting a design doc.
>

And the question is: once someone invents a kind of svn:special node
(besides "link"), how would Ev2 represent it?

Daniel

> > The current design of a pseudo-file is ridiculous.
>
> I agree that better designs are possible. Certainly the pseudo-file
> approach should be an implementation detail of the wire protocol.
> However, I would hesitate to invent actual new node types because they
> cannot be represented in older repositories, making the client<->server
> compatibility problem harder.
>
> > wc_db and Ev2 break out the three node types that we deal
> > with: dir, file, symlink. As part of that symlink was added to
> > svn_node_kind_t, so that we can talk about symlinks as first-class
> > items.
>
> Later in that same IRC log I concluded that talking about symlinks to
> the WC makes sense, as they're something most filesystems know about.
>
> > The svn:special design is horrible. For backwards compat and wire
> > protocol purposes, we'll always have to deal with it, but we can fix
> > our top-level APIs.
>
> That depends on what you call a top-level API; mine for symlinks is
> called "ln" :)
>
> -- Brane
>
>
> --
> Branko Čibej | Director of Subversion
> WANdisco // Non-Stop Data
> e. brane_at_wandisco.com
Received on 2013-06-28 02:02:29 CEST

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.