[bringing back onlist]
On Sat, Sep 20, 2008 at 12:51 AM, Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
> [ off-list? intentionally? ]
>
> Greg Stein wrote on Fri, 19 Sep 2008 at 20:00 -0700:
>> On Fri, Sep 19, 2008 at 5:42 AM, Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
>...
>> > (Also, what does switched mean here? Switched relative to the parent, or
>> > relative to the wc root?)
>>
>> Well... it really doesn't matter. The point is that the local_relpath
>> does not imply the repository path. If a subdirectory "realigns" with
>> the local/repos path correspondence, then fine. I believe our general
>> definition is "different from what parent implies".
>
> Agreed. But we can check that easily in wc1, because both parent and
> child have their full repository URLs stored.
>
> However, (and maybe this is what I was getting at initially), if we
> don't always store repos_path -- if we allow it to be NULL -- then how
> do we interpret "repos_path == NULL"?
>
> If it means "Same as nearest non-NULL parent", then we have to recurse
> up the tree to figure out the repos_path of a deep dir; and if it means
> "Same as wc root", it'll just be repeated needlessly when the root of
> a deep tree is switched. (Maybe either of these isn't a problem, but
> I want to point it anyway.)
>
>
> Example: Given these entries, is /A/B/E switched to /branch or not?
>
> NAME REPOS_PATH
> wc/ /trunk
> wc/A /branch/A
> wc/A/B NULL
> wc/A/B/E NULL
/A/B/E is on the branch, yeah. NULL should be <parent_repos_path + filename>
I think recursing up the tree should not be a problem.
Thanks for helping to clarify this, too.
>...
>> Let's say microseconds... APR date/time values, that is.
>
> Okay. As long as we don't lose precision, I'm happy; we can bikeshed
> the representation later.
:-)
>...
>> Yup. I figured it would be encoded in the value. Something like
>> "M:abcdef..." or "S:abcdef..." for MD5 or SHA1.
>
> Seems reasonable.
Yeah. We do that in the FS, so I figured self-describing should be fine.
Cheers,
-g
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-09-20 15:04:11 CEST