[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: Greg Stein <gstein_at_gmail.com>
Date: Fri, 28 Jun 2013 01:04:26 -0400

On Fri, Jun 28, 2013 at 12:52 AM, Daniel Shahaf <danielsh_at_apache.org> wrote:
>...
> In second thought, this just moves the problem: the wc layer would want to call
> add_symlink() during a commit.
>
> But I'd like to avoid the ambiguity still: either add_symlink() or
> add_file(svn:special=yes), not both; either add_blockdev() or add_special(),
> not both. Not sure how we can avoid this...

My decision in Ev2 was to surface the direct types, and work with them
as long as possible (*). When you hit a compatibility barrier, then
you transform.

Something I learned a long while ago from Guido was to avoid:

foo(arg=False)
foo(arg=True)

def foo(arg):
  if arg:
    one_thing()
  else:
    other_thing()

The argument shouldn't exist. Just have fooFalse() and fooTrue().

In that vein, wc_db and Ev2 avoid the add(kind=KIND) form, as the args
and underlying work are different for each KIND. The arguments are:
<props,content,checksum> vs <props,children> vs <props,target>. (and
don't forget add_absent!)

I would continue to push a per-kind API, which collapses to
svn:special when it hits the FS. Or one day the FS will directly
handle the various node kinds. Or svn:special over http/svn, with the
collapse within RA. Or ...

Cheers,
-g

(*) kinda like we're doing with moves, fwiw
Received on 2013-06-28 07:05:05 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.