Greg Stein wrote on Fri, Jun 28, 2013 at 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 ...
>
So, to be explicit: calling add_symlink() when driving the FS commit
editor is a bug; calling add_file(svn:special='*', contents="link foo")
when driving the wc-ng update editor is also a bug.
I suppose we could have a wrapper editor that converts from one form to
the other, or validates that the "wrong" way to add a symlink isn't
used. If we code the assertions tightly enough [1], we might even be
able to avoid bugs.
Cheers,
Daniel
[1] which is made easier by the fact that alter_file() takes a contents
stream rather than a delta stream: we can cheaply check for
contents.startswith("link ").
> Cheers,
> -g
>
> (*) kinda like we're doing with moves, fwiw
Received on 2013-06-28 07:20:29 CEST