feature or bug?

[guo tang]

Matt,

In Issue 839, jglick is proposing using SHA1 as part of the file name if
current file name encoding method creating a file name
too long to be handled by OS. The file name to SHA1 encoding is very
straightforward.  The file name decoding requires reading
a dictionary file.

I am wondering do we really need the file name decoding function? It seems
the decoding is only used in
/hg/mercurial/streamclone.py, stream_out() function. Can we just return raw
file name there?

If we can get rid of file name decoding, maybe we can just use file name
SHA1 as .i and .d file name. That is simple. And we don't
need a dictionary file for SHA1 to file name  mapping either.  Simple too.
Then we will never run into file name too long problem.

I am very new to hg source code, and to python programming. So forgive me if
my idea sounds silly.

Regards,
Guo

On Jan 6, 2008 9:54 AM, Matt Mackall <mpm at selenic.com> wrote:

>
> On Fri, 2008-01-04 at 22:19 -0800, Jens Alfke wrote:
> > On 3 Jan '08, at 8:56 PM, Matt Mackall wrote:
> >
> > > Meh. I hate 'em too. But they exist. The new "store" format largely
> > > exists to deal with that, but then people go and make unreasonably
> > > long
> > > filenames.
> >
> >
> > Not as "unreasonable" as you may think. Characters in most Asian
> > alphabets tend to decompose into three bytes each in UTF-8. If the
> > filesystem's limit on filenames is 255 *bytes* (as it is in ext2/3 and
> > xfs), then that's only 85 *characters* in such an alphabet. That means
> > such limits get hit a lot earlier in such languages. (I've run into
> > this issue myself in my job, initially reported by Korean QA engineers.)
>
> It's a known issue, we're intending to deal with it.
>
> The fix, I fear, will not be an easy or a happy one. There are important
> advantages to having a fairly direct mapping of pathnames in the working
> directory to pathnames in the repository and I'm not keen on giving them
> up.
>
> --
> Mathematics is the supreme nostalgia of our time.
>
> _______________________________________________
> Mercurial mailing list
> Mercurial at selenic.com
> http://selenic.com/mailman/listinfo/mercurial
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20080115/dab09d06/attachment-0001.html>