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

more editor v2

From: Neels Janosch Hofmeyr <neels_at_elego.de>
Date: Tue, 01 Sep 2009 22:58:08 +0200

Hi Greg and All,

am busy with editor v2's API docs, and got another few considerations/questions.

() The new callbacks use a REL_PATH argument consistently. But the editor
interface really makes no restriction on the path whatsoever (yet). It seems
that it serves no purpose to call this REL_PATH instead of just PATH. But:

The usual case will be that producer and consumer agree on a base path, and
the paths passed to the callbacks are indeed relative. In that case, it
serves the consumer code readability to call it REL_PATH.

Furthermore, if we are to add a debug/validation layer that enforces the
constraints outlined by the API description, we might want to have some
checks against the paths passed, e.g. whether all children of an added
directory are indeed added later. In that case, it would also be good to
enforce a very specific path format, as in "this/is/a/path". Agreed?
(What's that called, "Subversion's internal path format"?)

() In the same line, add_directory()'s CHILDREN arg (apr_array_header_t) is
not defined yet. The simplest would be to define it as a list of mere names
of immediate children (basenames) that are to be added subsequently.

My intuition says this list should also pass the node kind or something.
What does the WC actually need to create an 'incomplete' node?

Sending this list "only" serves recovery in case the operation is
interrupted, right? Is it really necessary to do this list thing at all?
What's the use of 'incomplete' child nodes for recovery anyway?

Thanks for hints / opinions.
~Neels

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2389936

Received on 2009-09-01 23:01:21 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.