On Sun, Apr 8, 2012 at 4:35 AM, Greg Stein <gstein_at_gmail.com> wrote:
> One thought: maybe it is proper/appropriate to simply state that the
> relpath values *must* be repos_relpath values. IOW, that Ev2 drives
> are always in reference to a given repository; thus, all relpaths must
> be relative to that repos root.
>
> Our APIs historically have attempted to avoid reference to repos_root
> because I wanted resources to be standalone, rather than related to
> some other entity. Over time, that position was unquestionably wrong,
> and we've been moving away from it. Knowing "repos_root_url" is
> important, and helps in any number of ways.
>
> We're still isolated to a single repository (ie. repos_relpath implies
> no-foreign-merge), but I think we have headspace to fix that. For
> example, an Ev2 drive can easily negotiate the semantics of relpaths
> such as "1/foo/path" and "2/bar/path".
>
> Back to the original point: editor drives are *always* talking about
> versioned resources (?? call out wrongness), so maybe we can just
> state that an Ev2 drive is *always* talking about repos_relpath
> values. If one side is a working copy, then fine: just map those nodes
> against their repository node paths. Each item within an Ev2 drive
> concerns a versioned node; thus, we can always provide a
> repos_relpath.
>
> Whaddyathink?
Generally sane. Whenever we define something as a relpath, the first
question is usually "relative to what?" Being able to answer that
question consistently across editor invocations has great
maintainability implications.
For repos->wc drives, my initial thought was to have the "relpath
root" be the working copy root, but there are scenarios where that
doesn't play out too well. Commit test 28 "commit from disjoint
working copies" is one example, though we'd still have to do
repos_relpath->local_relpath->local_abspath translation on the client.
-Hyrum
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/
Received on 2012-04-09 17:26:28 CEST