Greg Stein wrote on Fri, Sep 17, 2010 at 07:22:12 -0400:
> On Thu, Sep 16, 2010 at 19:26, Daniel Shahaf <d...@daniel.shahaf.name> wrote:
> > Greg Stein wrote on Thu, Sep 16, 2010 at 00:59:59 -0400:
> >> On Wed, Sep 15, 2010 at 23:35, Daniel Shahaf <d...@daniel.shahaf.name>
> >> wrote:
> >...
> >> > If yes, then we infer that no two in-repository paths (which are
> >> > bytewise different) canonicalize to the same byte sequence. Which is
> >> > pretty useful precondition to have, i.e., what /can/ svn do on a legacy
> >> > repository where some two paths are bytewise-different yet Unicode-equal?
> >>
> >> This will be *very* difficult to manage. Even if a given repository
> >> somehow manages to rewrite history to "fix" the paths, then you may
> >> have an unknown number of downstream synchronized repositories to
> >> similarly fix.
> >>
> >> I think an answer might be to rely on the upcoming obliterate
> >> feature's "out of band" change descriptions. For example, a repository
> >> might tell a working copy, "hey: file XYZ was obliterated since you
> >> last talked to me. if you happen to have it, then get rid of it. I
> >> won't recognize it henceforth." You can see a similar descriptor sent
> >> to working copies or repositories that says "I recoded XYZ. update to
> >> the new encoding."
> >>
> >
> > I don't see why this needs to be special-cased? The server can simply
> > send "rename(NFD(é), NFC(é))" and the wc library can figure for itself
> > that it's inoperative for her in the same place she determines that
> > "rename('foo','FOO')" is inoperative for her (when the filesystem is
> > case-insensitive).
>
> When does the server send that? If the wc is at r1000, and the server
> is at r1000, then the standard update response is nil.
>
> Yet if an administrator comes along and renames the repository paths
> to NFC, then *something* needs to return in an update response. I see
> it as "not part of the update request", and that there is an
> out-of-band response that details such changes. ie. changes that occur
> outside the revision numbering flow.
>
i.e., out-of-band is one choice, and making it a proper revision is the
other choice.
?
> Cheers,
> -g
